Filebot - {anidb} matching

[simfreak101]

Hi,
I just discovered this while wrestling with the age old metadata issue of anime and jellyfin. I spent over 100 hours using file bot to rename all of the files on my NAS using the anidb matching schema. During that process it renames the folders with a {ID} tag with the name of the series and renames the individual episodes with the episode name located in anidb.
Right now i have Shoko importing my collection, but its finding 1000's of mismatched files. I am curious why this would be? The name should match what anidb has and it has the helper series ID in the folder name (the episode id is not added to the individual file names}

When i do manual match, it does seem to find the series right away and match the episodes as well. Im just curious why it wouldnt do that during the indexing process. I could do manual, but i am having another issue where saving the match takes minutes to perform. I am wondering if its slow because all of the workers are busy hashing the imports. From a CPU perspective hardly any utilization is happening with 48 threads and 50 workers. I dont know if i should just add more workers or if there is some other bottleneck i am running into.

[da3dsoul]

You seem to fundamentally misunderstand how Shoko works and why it exists. Shoko doesn't care how you've named your files. It uses hashes to match, which means that AniDB must know about the file. That means it can't be private (a self rip), remuxed, transcoded, or corrupted if you want it to be automatically recognized.

The next stable version will ship with a plug-in called offline importer, which does allow automatically...manually linking these files from their names.

[simfreak101]

i understand the hashing part, im just confused on why it cant use the name to match metadata.
I guess you might be right that some of the encodes i have from nyaa are unknown to anidb and that is probably the issue.

If we move that issue to the side. How to i get more utilization during the hash/queue process,, and speed up the manual matching mechanism. I've read the help file and it says i can change the number of workers to each process, but it doesnt explicitly say there is a way to simply increase the number of dynamic workers beyond the Threads+2 limit.
Right now my queue count is over 24000 and its been running for days. Im running the docker version.

[da3dsoul]

It can't use the name because it only cares about hashes. The next stable has the ability to also use the name with that plugin.

Under the Quartz section, MaxThreadPoolSize‎ allows you to override the worker count to higher.

[simfreak101]

That seems to be better. Im also a idiot, for some reason i didnt think it was doing a hash of the whole file like a checksum. But some other mechanism that didnt require doing a read operation of the entire file. I just looked at my nas and noticed its pulling 2500iops at 2.4gbs. So im clearly disk constrained. Now i better understand the hash worker limits. I also pulled down the xml files from the site and that seemed to help a lot with blocking.

Can you many better explain drop folders? Based on what i said above, i am guessing its better for any *arr to put anime into a 'import' folder which is maybe on faster local storage where it can be indexed/hashed, then setup a separate drop folder on the slower 'nas' bulk storage where jellyfin's media library is? Or do i have that reversed. Right now my import folder is the entire Jellyfin anime media library, and where all of the *arr apps will download directly do.

Thanks for your time :)