it needs to be a part of the UI, not a side effect of another function

needs to be fixed asap

Either I will need to disable this combination or improve word search perfomance

should not save themselves and should not enter the reclist branch on the server

sometimes you get really weird ones and perhaps there is a need to finetune

I should probably make it a priority. Even over the backend update mechanisms.

Ideally I want to migrate to a proper in memory database

make sure I am at least semi protected before releasing

Needs a fandom ignore button and fic hide button (outside of tagging UI)

Now that fics from authors is a thing, there needs to be a button to display all fics DB has from the same author.
Optionally need to be a button to tag them all quickly.

need to derive some dependency between the duration the fic has been running, amount of chapters, wordcount, favourites, fandom active years and max favourites per category

will need to show how much has been added and updated instead of how much was processed from webpages

Some strange shit is going on with fandoms of new fics, the fandoms seem to be multiplying endlessly.
Also, I really need a merged fandoms list with one main fandom and records for all the possible splittings between ff, ff/crossover. ao3... etc

More ways to slice fandoms would be nice.
Could calculate what average fic sheet looks like and work from there

iunno if needed

Would be interesting to explore. Give the user an ability to get results from one-of-the/last search by a random other user.

It seems there are legit cases where it's the fastest way to go

make an option to show fics that two ffn urls have in common

would be interesting to see which fics figure in large amounts of heterogenous lists

I think I can make one.
Will read user fav url and output fics in individual posts
Tracking should be done by emoji, then users will be able to rotate and clean up the list the same way they can now even if they wont be able to filter.

a legit use case would be when making a list and making sure there is no two fics from the same person

need to investigate why is it so slow on the server
reccount could also use speedup but that's likely unavoidable
revtofav is horrendously slow, probably error in the query

Only ever important for fir passes.
When a cat is unavailable and a fandom is parsed, the next incremental parse will likely miss a lot of fics.
It means the old question of "what to consider a dandom update date" still applies
Not very urgent but something to consider.

I can check the percentage of slash the author has written to detect teh false flagging of the original algo.

Fetching query sizes takes too long because DB needs to match too much tables to work properly.
Need to denormalize slash and fandoms at least
Slash data needs to move directly into the fanfic table.
Fandom data could probably be merged as numbers and queried with LIKE

Unless I explicitly cache the sequence, forming it on the server side for default parameters per user request is completely unrealistic

1. Shared memory
   Pros: init once
   Cons: boost.interprocess will take at least 3 days to implement

2. File serialization(Multiprocess Read)
   Pros: easier to setup
   Cons: it's still BS even as multiprocess

3. Limiting dataset
   Pros: easiest to implement
   Cons: can't debug anything even relatively complex

4. Log stuff
   Pros: perhaps the simpliest
   Cons: can't see stuff in real time.
   Will either have not enough info or horribly noisy logs.

shit's broken since client refactor. needs fixing

Idea for the future. ESRB is trash, there needs to be a writing style maturity rating

will improve usability but require treeview

so that user doesn't have to move the mouse a lot after tagging evrying