Sonarr: anime root folder is always discarded because the override check compares against the anime directory instead of the default

[Raffa2001]

Summary

With activeAnimeDirectory configured, anime requests are still added to Sonarr
using the default root folder. The anime directory is selected correctly and
then immediately overwritten by the request's own rootFolder, which the UI
stores as the server's default directory.

The equivalent Radarr branch in the same file does not have this problem — it
compares the override against the default directory. The Sonarr branch compares
it against the already-resolved value.

Where

server/subscriber/MediaRequestSubscriber.ts (current develop).

Sonarr, ~line 598:

let rootFolder =
  isAnime && sonarrSettings.activeAnimeDirectory
    ? sonarrSettings.activeAnimeDirectory     // -> /data/media/anime
    : sonarrSettings.activeDirectory;
...
if (
  entity.rootFolder &&
  entity.rootFolder !== '' &&
  entity.rootFolder !== rootFolder            // <-- compares to the RESOLVED value
) {
  rootFolder = entity.rootFolder;             // -> back to /data/media/tv
}

Radarr, ~line 249, for contrast:

if (
  entity.rootFolder &&
  entity.rootFolder !== '' &&
  entity.rootFolder !== radarrSettings.activeDirectory   // <-- compares to the DEFAULT
) {

For anime the two are different by definition, so a stored rootFolder that is
merely the default is treated as a deliberate override and always wins. The
anime directory can therefore never take effect for a request that carries one.

Observed

Sonarr server settings:

activeDirectory	/data/media/tv
activeAnimeDirectory	/data/media/anime
activeProfileId	7
activeAnimeProfileId	4

Request row in the database:

id=57  type=tv  rootFolder='/data/media/tv'  profileId=4

What was sent to Sonarr (from the debug log):

rootFolderPath    '/data/media/tv'      <-- default, not the anime directory
qualityProfileId  4                     <-- anime profile, correctly applied
seriesType        'anime'               <-- detected as anime

So anime detection works and the anime profile is applied; only the
directory is lost. Two consecutive anime requests reproduced it, and both had
to be moved by hand in Sonarr afterwards.

Version: v3.4.1 (latest release at the time of writing). The logic above is
unchanged in develop; commit 93c0b6a (decouple anime root folder routing from seriesType) touches the selection but not the override comparison.

Suggested fix

Make the Sonarr branch match the Radarr one:

-          entity.rootFolder !== rootFolder
+          entity.rootFolder !== sonarrSettings.activeDirectory

An explicit override that genuinely differs from the default still wins; one
that merely echoes the default no longer defeats the anime directory.

[github-actions]

Possible duplicate detected

This issue may be a duplicate of the following (detected via semantic similarity + LLM review):

• Anime requests fail with "Quality Profile does not exist" when activeAnimeProfileId is stale #3159 (75% match) — Anime requests fail with "Quality Profile does not exist" when activeAnimeProfileId is stale
• Anime Series are Added with TV Show Settings #3244 (67% match) — Anime Series are Added with TV Show Settings
• [FR] add 'Search Automatically' and 'Request New Seasons' options to request dialog #1047 (56% match) — [FR] add 'Search Automatically' and 'Request New Seasons' options to request dialog

A maintainer will review this. If this is not a duplicate, no action is needed.

[fallenbagel]

Closing. No template (no fields filled in, no template-applied labels and thus this went straight to blocked:template), and the writing reads like raw unreviewed model output. The AI policy in CONTRIBUTING.md applies to issues just as much as PRs as it's still a contribution.

Bypassing the template is its own violation here, separate from the AI content. It exists to get the information we actually need up front and route reports through triage correctly. You went around it and pasted in raw output instead. That skips the part of the process that takes effort. In otherwords, the part that is, your homework. Your contribution. Why should we waste time verifying your claim when you couldn't even be bothered to take five minutes to write the issue in your own words?

Posting a model's raw diagnosis as your own report isn't a contribution. It's homework you didn't do, handed to a maintainer to verify on your behalf. A second opinion from a model is fine, but you still need to read it, understand it, and write the report yourself. Don't be a meat proxy. If you're just going to drive by with raw output, we don't need you in the thread at all, we can ask AI ourselves.

To be clear, I'm not saying there's no bug here. I'm saying I'm not reading a regurgitated essay and doing the verification work myself to find out. If there's a real bug here, I'd rather find out through your own investigation than through pasted output. Resubmit through the template, in your own words, with AI assistance disclosed per the contribution guidelines if you used any. Happy to look at it from there.