feat: Adding anime specific Sonarr/Radarr instance support

[speatzle]

Description

This change adds the option to set a Sonarr or Radarr service as an Anime specific instance.
Adding this helps a number of people who are runnign two instances for separating anime and regular tv shows.

Ported from sct/overseerr#3664

Thanks to @thempc

Screenshot (if UI-related)

To-Dos

• Successful build pnpm build
• Translation keys pnpm i18n:extract
• Database migration (if required)

Issues Fixed or Closed

• Fixes Allow dedicated sonarr/radarr instances for anime #232

[github-actions]

This pull request has merge conflicts. Please resolve the conflicts so the PR can be successfully reviewed and merged.

[samtheruby]

There is a issue where when Anime Server is checked for a Sonarr Service; even if all the required fields are filled out, the save changes button is always greyed out

[github-actions]

This pull request has merge conflicts. Please resolve the conflicts so the PR can be successfully reviewed and merged.

[balgerion]

This is absolutely awesome! Is there chance to merge it to main build ?

[thempc]

I'm eagerly awaiting this so I can switch to Jellyseer :D

[Kariton]

is something specific holding this MR back?

[engels74]

is something specific holding this MR back?

Not sure if it's the same as on the Overseerr equivalent PR, but it has been sat idle for so long, it now requires some work to fit with current upstream. Thempc (the original author) has stated in the original Overseerr PR he doesn't really want to maintain it, as it's been stale for so long.

So in short - it needs some work to solve merge conflicts :)

[MisterQnl]

Hey @speatzle, I took a pass at unblocking this. I rebased your anime-server branch onto the latest develop branch, resolved the merge conflicts and verified build/lint locally.

The result is here on my fork: MisterQnl/jellyseerr:anime-server-rebased. Link

Happy to proceed however you prefer:

1. You keep this PR: You can update your branch from mine, or
2. I open a new PR to fallenbagel:develop that supersedes this one and credits you as the original author.

No pressure! I won’t open a new PR unless you’d like me to. 👍

[speatzle]

Hey @MisterQnl, afaik @gauthier-th took over this pr after our conversion in #232 i haven't touched it since. I am unsure why it wasn't merged back then.

[MisterQnl]

Thanks for the quick reply @speatzle!
Hi @gauthier-th, following up on @speatzle’s note above. I rebased the branch and fixed the merge conflicts; lint/build pass. I haven’t validated any functionality.

Branch on my fork: MisterQnl/jellyseerr:anime-server-rebased. Link

What’s your preferred next step: should I open a PR to the develop branch that supersedes this one, or would you rather update this PR from my branch?

[samtheruby]

@MisterQnl I had a issue building a docker container where 2 libraries needed to be commented out due to duplication

Specifically in src/components/Settings/SonarrModal/index.tsx:
Line 11: //import { useSettings } from '@app/hooks/useSettings'; and
Line 12: //import { MediaServerType } from '@server/constants/server';

Both of these needed to be commented out due to duplication earlier in the same code.

[MisterQnl]

Thanks for letting me know @samtheruby!
Fixed and pushed.

[Smexhy]

Now that the TVDB support was merged, will this affect things with this PR at all in the future?

[samirbilalmemon]

Now that the TVDB support was merged, will this affect things with this PR at all in the future?

I don't think so since tmdb is used to identify if media is anime and I don't think that would affect this also tvdb is not being used as a replacement, instead it is being used as as optional metadata provider.

[samirbilalmemon]

Pinging this PR so it doesn't become stale.

[samirbilalmemon]

@MisterQnl would it be possible for you to bring your fork up to speed with current develop branch and make a docker image? The current develop branch has added tvdb indexer support and that is pretty great for Sonarr integration.

[MisterQnl]

@samirbilalmemon Done 😄
I do wonder what is the timeline on when this PR gets merged? @fallenbagel @gauthier-th
Or what would be needed to get this live? It has been a few months already

[samirbilalmemon]

@MisterQnl Thank you. I suspect it could be that the pull request referencing speatzle:anime-server is causing confusion and maybe your fork is not being viewed.

I tried downloading anime-server-rebased.zip from your fork and extracting it and then cd into it. Then I ran docker build -t jellyseerr:mqnl -f Dockerfile . and added it to my docker-compose.yml and now when I run it I get stuck on a screen saying Jellyseerr updated please click the button to reload the application and even after clicking it I can't progress. I am probably doing something wrong since trying to build from the main fallenbagel repo is also resulting in the same. The only way I seem to get jellyseerr to work is by pulling from docker hub but that doesn't have your fork. Nevermind I realise this issue has the solution and it worked #687 My working command was docker build --tag MisterQnl/jellyseerr:anime-server-rebased --build-arg COMMIT_TAG=4c9aee8 .

[LaurenceBarnes]

I'd like to add that an improved approach to Override rules would be a more scalable solution to this.

See my issue #1560 for reference.

[LaurenceBarnes]

And a successful merge of #1865 would make this PR obsolete

[samtheruby]

And a successful merge of #1865 would make this PR obsolete

Sorry, unless I'm missing something how does that PR make this one obsolete they solve 2 different issues.

[LaurenceBarnes]

And a successful merge of #1865 would make this PR obsolete

Sorry, unless I'm missing something how does that PR make this one obsolete they solve 2 different issues.

Because it does the exact same thing (sending anime to defined instances), but more individually, with a lot more options to do other things as well.

[bin101]

And a successful merge of #1865 would make this PR obsolete

Sorry, unless I'm missing something how does that PR make this one obsolete they solve 2 different issues.

I understand the confusion, the other PR let's you map radarr/sonarr instances by e.g. TVDB/TMDB keywords/genres. So you can say everything containing the keyword "anime" goes to instance X but also every action movie goes to instance Y

[MisterQnl]

#1865 Looks good, I have not tested it myself. If it all works great and well with the tagging of keywords then it would make this PR obsolete.
Then again that choice is up to @gauthier-th and @fallenbagel

[Soitora]

Sorry, unless I'm missing something how does that PR make this one obsolete they solve 2 different issues.

Because it does the exact same thing (sending anime to defined instances), but more individually, with a lot more options to do other things as well.

Should we also just remove Series and Movies categories and let everything be handeled by that?
I think Anime is a big enough media that it warrants its own category (like this PR). But the linked PR is helpful for my other sub-Series categories like K-drama and other stuff

[LaurenceBarnes]

Sorry, unless I'm missing something how does that PR make this one obsolete they solve 2 different issues.

Because it does the exact same thing (sending anime to defined instances), but more individually, with a lot more options to do other things as well.

Should we also just remove Series and Movies categories and let everything be handeled by that? I think Anime is a big enough media that it warrants its own category (like this PR). But the linked PR is helpful for my other sub-Series categories like K-drama and other stuff

It is more that it would create redundancy that isn't really needed imo. The default 4k/standard separation that we already have is good, but Anime can be filtered really well by keywords. Note that this PR was created before override rules were added, so that is the main reason why a different approach wasn't thought of.

[zwimer]

As I understand it, override rules are ignored for auto-approved requests. See #1195

The thing to note is, override rules will not be applied to admins/auto_approve permission users.

So this PR has that as a very large benefit over any solution based on override rules imo, unless something has changed regarding this point. It'd be very weird to have only half your users have their anime send to the anime Sonarr instance, but all admin's / trusted users with the auto_approve permission have their anime sent to the TV Sonarr instance.

[laitco]

As I understand it, override rules are ignored for auto-approved requests. See #1195

The thing to note is, override rules will not be applied to admins/auto_approve permission users.

So this PR has that as a very large benefit over any solution based on override rules imo, unless something has changed regarding this point. It'd be very weird to have only half your users have their anime send to the anime Sonarr instance, but all admin's / trusted users with the auto_approve permission have their anime sent to the TV Sonarr instance.

Maybe an option within the override rules section/general tab is needed to apply the override rules as well for the auto approved ones. Could this help? Should be possible to implement the override rule logic beforehand the request is automaticlly approved.

[laitco]

As I understand it, override rules are ignored for auto-approved requests. See #1195

The thing to note is, override rules will not be applied to admins/auto_approve permission users.

So this PR has that as a very large benefit over any solution based on override rules imo, unless something has changed regarding this point. It'd be very weird to have only half your users have their anime send to the anime Sonarr instance, but all admin's / trusted users with the auto_approve permission have their anime sent to the TV Sonarr instance.

Maybe an option within the override rules section/general tab is needed to apply the override rules as well for the auto approved ones. Could this help? Should be possible to implement the override rule logic beforehand the request is automaticlly approved.

Override rules apply to auto-approve users, like @fallenbagel mentioned in #1865 (comment) and #1865 (comment).

[zwimer]

Override rules apply to auto-approve users, like @fallenbagel mentioned in #1865 (comment) and #1865 (comment).

It seems you are correct. Unfortunately, since they do not apply to those with advanced requests, I think this PR still provides benefits compared to the alternatives (unless there is some way to have it apply to all users' requests).

[fallenbagel]

Override rules apply to auto-approve users, like @fallenbagel mentioned in #1865 (comment) and #1865 (comment).

It seems you are correct. Unfortunately, since they do not apply to those with advanced requests, I think this PR still provides benefits compared to the alternatives (unless there is some way to have it apply to all users' requests).

Override rules are planned to apply to them as well. Current Override rules are very barebones because our focus is the merger but a more advanced Override rules are planned.

[shwarnock]

There hasn't been any update here in over a month. Is this something still planned? I would very much like to take advantage of this.

[Feramance]

I have an overseerr container with this change included, though admittedly slightly differently which in my opinion is also much better to configure: feramance/overseerr:nightly

[samtheruby]

Bug Fix: Anime requests from non-admin users routing to wrong server

@MisterQnl Not sure if you are still working on or doing anything with your PR, but I've been testing the PR again and found a bug where anime requests from users without the "Advanced Requests" permission are being routed to the default 1080p Radarr/Sonarr instance instead of the anime-specific instance.

Cause

The override rules logic in MediaRequest.ts (lines 221-226) only considers the is4k flag but ignores the isAnime flag when selecting default servers for non-admin users. The 4K routing works correctly because it checks is4k, but anime routing is missing the equivalent isAnime check.

Current behavior:

• Admin users → Works correctly
• Users with "Advanced Requests" permission → Works correctly
• Users without "Advanced Requests" permission → Broken (routes to default 1080p instance)

The Fix

The isAnime flag needs to be added to the server selection logic in the override rules, matching the pattern already used in sendToRadarr() and sendToSonarr(). Three files need updates:

---

1. server/entity/MediaRequest.ts (lines 220-247)

Before:

if (useOverrides) {
  const defaultRadarrId = requestBody.is4k
    ? settings.radarr.findIndex((r) => r.is4k && r.isDefault)
    : settings.radarr.findIndex((r) => !r.is4k && r.isDefault);
  const defaultSonarrId = requestBody.is4k
    ? settings.sonarr.findIndex((s) => s.is4k && s.isDefault)
    : settings.sonarr.findIndex((s) => !s.is4k && s.isDefault);

After:
if (useOverrides) {
  let defaultRadarrId = requestBody.is4k
    ? settings.radarr.findIndex(
        (r) => r.is4k && r.isDefault && r.isAnime === requestBody.isAnime
      )
    : settings.radarr.findIndex(
        (r) => !r.is4k && r.isDefault && r.isAnime === requestBody.isAnime
      );
  // Fallback for requesting anime if there is no default anime server
  if (defaultRadarrId === -1 && requestBody.isAnime) {
    defaultRadarrId = requestBody.is4k
      ? settings.radarr.findIndex((r) => r.is4k && r.isDefault)
      : settings.radarr.findIndex((r) => !r.is4k && r.isDefault);
  }

  let defaultSonarrId = requestBody.is4k
    ? settings.sonarr.findIndex(
        (s) => s.is4k && s.isDefault && s.isAnime === requestBody.isAnime
      )
    : settings.sonarr.findIndex(
        (s) => !s.is4k && s.isDefault && s.isAnime === requestBody.isAnime
      );
  // Fallback for requesting anime if there is no default anime server
  if (defaultSonarrId === -1 && requestBody.isAnime) {
    defaultSonarrId = requestBody.is4k
      ? settings.sonarr.findIndex((s) => s.is4k && s.isDefault)
      : settings.sonarr.findIndex((s) => !s.is4k && s.isDefault);
  }

---
2. server/subscriber/MediaRequestSubscriber.ts (Radarr section, around line 194)

Before:
let radarrSettings = settings.radarr.find(
  (radarr) => radarr.isDefault && radarr.is4k === entity.is4k
);

After:
let radarrSettings = settings.radarr.find(
  (radarr) =>
    radarr.isDefault &&
    radarr.is4k === entity.is4k &&
    radarr.isAnime === entity.isAnime
);

// Fallback for requesting anime if there is no default anime server
if (!radarrSettings && entity.isAnime) {
  radarrSettings = settings.radarr.find(
    (radarr) => radarr.isDefault && radarr.is4k === entity.is4k
  );
}

---
3. server/subscriber/MediaRequestSubscriber.ts (Sonarr section, around line 464)

Before:
let sonarrSettings = settings.sonarr.find(
  (sonarr) => sonarr.isDefault && sonarr.is4k === entity.is4k
);

After:
let sonarrSettings = settings.sonarr.find(
  (sonarr) =>
    sonarr.isDefault &&
    sonarr.is4k === entity.is4k &&
    sonarr.isAnime === entity.isAnime
);

// Fallback for requesting anime if there is no default anime server
if (!sonarrSettings && entity.isAnime) {
  sonarrSettings = settings.sonarr.find(
    (sonarr) => sonarr.isDefault && sonarr.is4k === entity.is4k
  );
}

[fallenbagel]

superseded by #2452, which adds support for anime specific instance support for both radarr/sonarr via instance switching.

[speatzle]

@fallenbagel is there an easy way to trigger the down migration? Id like to Upgrade my instance whenever #2452 is ready.

[fallenbagel]

@fallenbagel is there an easy way to trigger the down migration? Id like to Upgrade my instance whenever #2452 is ready.

What do you mean by down migration?

[speatzle]

@fallenbagel I mean the Database Down/Revert Migration, i could get the SQL and run it manually but i thought there may be a builtin way.

[fallenbagel]

@fallenbagel I mean the Database Down/Revert Migration, i could get the SQL and run it manually but i thought there may be a builtin way.

Yes. Typeorm allows for that. Thats what the DOWN() in migration files are for.

pnpm exec ts-node -r tsconfig-paths/register --project server/tsconfig.json ./node_modules/typeorm/cli.js migration:revert -d server/datasource.ts

will undo them one at a time.

Do backup your db though because I've never tested this either and it's reliability is unknown, atleast for me.