Difegue
Total entries doesn't match the showing archives and actual archives inside the folder.
LRR Version and OS Latest, Docker install on UNRaid with custom template
Bug Details Total entries doesn't matches archives, I've 9155 cbz files, the system says that the total entries are way more: 9902 and it shows only 9144 even without any filters, is possible to trim the entries that are not linked to any archive (I tried clean DB, didn't change anything) and to show what archives are not linked (11 are missing in my case, but I added them all togheter so I have no clue what are the ones missing)
Screenshots
I have the same problem in the opposite direction.
@AbyssalMonkey that's even more stranger, I managed to solve my issue, but it took a lot to figure it out: the total entries are generated per archive (or should) but if you rename the archives it will add +1, in my case I renamed a tons of archives, and this got solved by simply restarting the Shinobu Watcher, I did few test and apparently if you rename an archive, and then name it back it will disappear from the library and it will counts 2 total entries, to solve this you need to first clean DB and then restart the Shinobu Watcher, the manga will re-appear on the library and the entries will get fixed. While testing I noticed that adding too many cbz to the archive will crash the Shinobu Watcher in some case (over 1000 files at the time) and in other case (always if not crash) it will count thousand of records less, in this case the only fix I found was to restart the docker application entirely. So try to do all of them and see if it fixes for you, clean DB, restart the Shinobu Watcher, and restart the LANraragi server.
Last thing apparently the FAKKU crawler metadata seems to not work properly at all, both on batch and single filter, for most cases it does but for case with "chapter - 1" like this one: https://www.fakku.net/search/shady%20dealings%20chapter most tags will be taken from the last one ( chapter - 4 in that case) this seems to happens to every single series with multiple chapters in the name and not only that but even in case 1 author has many works in some cases it picks another work from that author instead the correct one (I noticed this thanks to the incorrect Magazine tags in a lot of them) I tried to manually fix it, but after 1k edits I gave up.
Thanks for the detailed report.
I'm suspecting this is due to the filewatcher not cleaning up its internal filemap properly when rename operations happen. Restarting it prompts a filemap rebuild, which as you saw fixes the issue.
The total count is currently based on said filemap, so you shouldn't be too worried if it drifts from the real count a bit.
I'm hoping to resolve this alongside #555, since adding more search-specific tables should allow for more precision.
As for the FAKKU crawler, I should probably stick this somewhere in its description but it's as accurate as it gets given what we're working with. (the F! search in this case)
You might notice that searching for https://www.fakku.net/search/shady%20dealings%20chapter%201 to get a specific chapter doesn't work; I recommend using the Chaika plugin first and only falling back to FAKKU if you can't get your tags any other way.
With #555, we now use the new title/ID index instead of the filemap to determine total count.
This won't really be more accurate since if you delete files from your filesystem without going through the app, the ID will remain in the DB, leading to a different count from what's really on your FS.
But it will at least always represent the total n° of IDs stored in the database, instead of fluctuating based on weird filesystem events.
I don't plan on doing anything else about this issue. 🤷