Teaching the arrs to skip Russian and very long releases

Sonarr blew up at 3 AM with PathTooLongException thrown across the import queue. The release that triggered it was a translated upload with a 250-character filename. By morning the whole import pipeline was wedged.

What was happening

Two things compounded:

A release group was uploading episodes with massively long Cyrillic filenames — "translated", with cast, episode title, and release notes baked into the file basename
.NET on the import side has a path length limit; ext4 on the Synology has a NAME_MAX=255 byte limit on individual filename segments

Cyrillic is multi-byte in UTF-8. A "200 character" Cyrillic filename can be 400 bytes. Combine that with a long destination path tree and you trip PathTooLongException before the file even gets written. Sonarr retries, fails identically, and starts log-flooding.

What I found

The right place to fix this is at the indexer layer, not the import layer. Sonarr and Radarr both have a "Release Profile" feature with a "Must Not Contain" rule that takes regex. Three rules cover the failure modes I'd actually seen:

Any Cyrillic character
Specific release groups that consistently produce these uploads
Any release name with a 200+ character run anywhere in it

That prevents the grab from ever entering the queue, instead of trying to clean up after the fact.

The fix

Create one release profile on each arr, applied to all indexers (indexerId: 0 = all). The ignored list:

/[Ѐ-ӿ]/
HDrezka
LostFilm
LE-Production
Red Head Sound
NovaFilm
Kerob
/.{200,}/

Push it via the API:

curl -X POST "$SONARR/api/v3/releaseprofile" \
  -H "X-Api-Key: $KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Block Cyrillic + long releases",
    "enabled": true,
    "required": [],
    "ignored": ["/[\\u0400-\\u04FF]/", "HDrezka", "LostFilm", "/.{200,}/"],
    "tags": [],
    "indexerId": 0
  }'

Same payload on the Radarr side. The regex syntax (slashes around the pattern) tells the arr to treat the string as regex rather than a literal substring.

If a release ever slips through anyway and starts log-flooding, the watchdog shape I sketched but didn't deploy:

# cron every 5 min
count=$(journalctl -u sonarr --since "10 min ago" | grep -c "PathTooLongException")
if [ "$count" -gt 5 ]; then
  # find the offending torrent hash in qBittorrent, delete + blocklist
  # restart sonarr
  ...
fi

I deliberately didn't deploy that one. If the release profile is working, the watchdog should never fire. If it does fire, that's a signal the profile needs another rule, and the right response is to add it, not to automate around it.

What I'd do differently

The lesson is "filter at the earliest layer that has the information." PathTooLongException happens at import, but everything you need to make the decision — the release name — is available at indexer-search time. Same idea generalizes: don't let bad data through three layers and then try to clean it up at the bottom. Drop it at the door.