Before submitting your feature request, please verify the following.
Current Feature
Shoko's ProcessFileJob always queues a GetAniDBFileJob for every newly-discovered file. The job hits AniDB's UDP FILE command with the file's ED2K hash, rate-limited at the configured UDP base rate (source default 2s, AniDB's documented floor). There's no way to opt out: every file gets a UDP lookup, every time it's rediscovered, regardless of whether the user expects any of their files to match AniDB's hash database.
This is correct behaviour for vanilla anime libraries containing untouched original releases. AniDB's UDP database holds the canonical hash for each file the community has dumped, and matching enables automatic episode linking, group attribution, and MyList sync.
It is the wrong behaviour for re-encoded libraries. Users with custom transcodes (HEVC conversions, anime-style mini-encodes, future AV1/AV2 migrations) hold files whose hashes have never been and will never be in AniDB's database. The UDP lookup will return "not found" for every file, every time, forever.
Feature Changes
Add a per-import-folder setting: Use AniDB hash matching for files in this folder (default: on, for backward compatibility).
When set to off, ProcessFileJob skips the GetAniDBFileJob entirely for files in that import folder. Files still get hashed locally (ED2K cached for future use, and CRC32 when enabled), MediaInfo runs, the CrossRef step still resolves user-supplied links, but no UDP call to AniDB occurs.
The setting is a no-op for users with vanilla libraries. For users with re-encoded libraries, it eliminates the entire UDP-bound cascade and the associated ban risk.
Concrete numbers from my setup:
I have a 13,000-file anime library, almost entirely re-encoded. None will ever hash-match AniDB. I link files via a custom bulk-link script using the TVDB to AniDB cross-reference from anime-list-master.xml. All my CrossRef rows have Source: User.
Today, any filesystem reorganisation triggers a UDP-bound cascade. Renaming ~40 series folders via Sonarr's moveFiles=true generated ~1,600 ProcessFileJobs, all gated by the UDP rate limit, all returning "not found", consuming ~2 hours and triggering a fresh AniDB ban.
Future codec migration (h264 to AV1, eventually AV2) will be worse. Every file gets a new ED2K hash. Tens of hours of UDP work, multiple bans, zero useful information.
The opt-out is impossible today. Setting UDPServerAddress=127.0.0.1 causes the rate-limit penalty mode to engage and blocks 15 UDP-bound job types via AniDBUdpRateLimitedAcquisitionFilter. There's no setting to disable just GetAniDBFileJob, no setting to opt a folder out of UDP, and MaxAutoScanAttemptsPerFile is bypassed by ForceAniDB: true.
A per-folder toggle keeps the default behaviour intact, lets vanilla users keep AniDB auto-matching, and gives re-encoded-library users a way out.
Related: #1182 (open, HTTP ban pressure, same family of pain). Precedent: #1294 (closed completed, MyList opt-out, same theme of letting users disable AniDB UDP traffic they don't need).
Feature Examples
No response
Before submitting your feature request, please verify the following.
Current Feature
Shoko's ProcessFileJob always queues a GetAniDBFileJob for every newly-discovered file. The job hits AniDB's UDP
FILEcommand with the file's ED2K hash, rate-limited at the configured UDP base rate (source default 2s, AniDB's documented floor). There's no way to opt out: every file gets a UDP lookup, every time it's rediscovered, regardless of whether the user expects any of their files to match AniDB's hash database.This is correct behaviour for vanilla anime libraries containing untouched original releases. AniDB's UDP database holds the canonical hash for each file the community has dumped, and matching enables automatic episode linking, group attribution, and MyList sync.
It is the wrong behaviour for re-encoded libraries. Users with custom transcodes (HEVC conversions, anime-style mini-encodes, future AV1/AV2 migrations) hold files whose hashes have never been and will never be in AniDB's database. The UDP lookup will return "not found" for every file, every time, forever.
Feature Changes
Add a per-import-folder setting:
Use AniDB hash matching for files in this folder(default: on, for backward compatibility).When set to off, ProcessFileJob skips the GetAniDBFileJob entirely for files in that import folder. Files still get hashed locally (ED2K cached for future use, and CRC32 when enabled), MediaInfo runs, the CrossRef step still resolves user-supplied links, but no UDP call to AniDB occurs.
The setting is a no-op for users with vanilla libraries. For users with re-encoded libraries, it eliminates the entire UDP-bound cascade and the associated ban risk.
Concrete numbers from my setup:
I have a 13,000-file anime library, almost entirely re-encoded. None will ever hash-match AniDB. I link files via a custom bulk-link script using the TVDB to AniDB cross-reference from anime-list-master.xml. All my CrossRef rows have
Source: User.Today, any filesystem reorganisation triggers a UDP-bound cascade. Renaming ~40 series folders via Sonarr's
moveFiles=truegenerated ~1,600 ProcessFileJobs, all gated by the UDP rate limit, all returning "not found", consuming ~2 hours and triggering a fresh AniDB ban.Future codec migration (h264 to AV1, eventually AV2) will be worse. Every file gets a new ED2K hash. Tens of hours of UDP work, multiple bans, zero useful information.
The opt-out is impossible today. Setting
UDPServerAddress=127.0.0.1causes the rate-limit penalty mode to engage and blocks 15 UDP-bound job types viaAniDBUdpRateLimitedAcquisitionFilter. There's no setting to disable just GetAniDBFileJob, no setting to opt a folder out of UDP, andMaxAutoScanAttemptsPerFileis bypassed byForceAniDB: true.A per-folder toggle keeps the default behaviour intact, lets vanilla users keep AniDB auto-matching, and gives re-encoded-library users a way out.
Related: #1182 (open, HTTP ban pressure, same family of pain). Precedent: #1294 (closed completed, MyList opt-out, same theme of letting users disable AniDB UDP traffic they don't need).
Feature Examples
No response