feat: Adding anime specific Sonarr/Radarr instance support

[thempc]

re #2876

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.

Screenshot (if UI-related)

Adding or Editing services:

To-Dos

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

Issues Fixed or Closed

• Fixes Sonarr for anime only - remove requirement #2876

[thempc]

This is my first time contributing here, so I'm sure there's something I've done wrong :) please let me know.
I've also just done this based on both my own needs and seemingly the needs of others (looking at the multiple tickets + threads on Discord)

[Feramance]

Please make this so

[thempc]

I've noticed that with the current pull request any Anime requests will not fallback to the regular default service instance if there is no default anime service. Making this a breaking change. I think it would be better if this wasn't a breaking change so I will update this with a small ammentmend to make it have a fallback.

[thempc]

Validated this does now correctly use fallbacks. When requesting anime with just a single default server without changing any settings related to this change, Overseerr will send the request to the default instance. When afterwards setting up another Sonarr instance with the Anime default flag enabled, it routes the requests there instead.

[Feramance]

Might I suggest a slight change to mark the anime settings as required, and normal settings as not required in the event that it is an anime instance?

[thempc]

Might I suggest a slight change to mark the anime settings as required, and normal settings as not required in the event that it is an anime instance?

I unfortunately don't understand the suggestion. If you could elaborate that would be great.

[Feramance]

Might I suggest a slight change to mark the anime settings as required, and normal settings as not required in the event that it is an anime instance?

I unfortunately don't understand the suggestion. If you could elaborate that would be great.

As you can see below, the asterisks are denoting the fields are required. Now when setting up an anime server, I imagine that its not the general quality/root folder you are using, but the anime quality/root folder. Therefore is it possible to have the required quality/root folder fields for anime be set to required, while the general ones set to not required when the isAnime tick box is ticked?

[thempc]

@Feramance as requested, the previous commit marks the Anime-specific dropdown as required. It however does not mark the normal ones as not required. This is because I couldn't find a logical flow in which those could be optional.

[OwsleyJr]

@Feramance as requested, the previous commit marks the Anime-specific dropdown as required. It however does not mark the normal ones as not required. This is because I couldn't find a logical flow in which those could be optional.

Not sure how I feel about having two options for profile, folder, etc. when this is for an anime specific Sonarr. The flow would either need to be modified to remove/hide one of them or just completely disable a set of options.

[thempc]

Hmmm, well I can understand that hiding it would be better. So, I would like to suggest the following scenarios:

• A user has one server, marked as a regular default server (nothing changes, it accepts both TV and Anime)
• A user has two servers, one marked regular default and one anime default (here we change the anime interface to hide the regular TV options)
• A user has one server, marked as default anime (show only the anime settings, and display an error that there is no regular default server)

This should keep backwards compatibility and give the UI a cleaner look. If this is acceptable I will implement this.

[Feramance]

Hmmm, well I can understand that hiding it would be better. So, I would like to suggest the following scenarios:

• A user has one server, marked as a regular default server (nothing changes, it accepts both TV and Anime)
• A user has two servers, one marked regular default and one anime default (here we change the anime interface to hide the regular TV options)
• A user has one server, marked as default anime (show only the anime settings, and display an error that there is no regular default server)

This should keep backwards compatibility and give the UI a cleaner look. If this is acceptable I will implement this.

I do have one other suggestion, though a little extra, it should make everything cleaner.

• Add another tick box labeled Series
• Default Sonarr service will show fields for both Series and Anime
• If Series is selected then only the fields for general series are shown
• if Anime is selected then only the fields for anime are shown

This both keeps backwards compatibility and more granular control on what service handles what

[thempc]

I'm fine with either of the above, @OwsleyJr if you could pass your verdict on whichever you prefer, I'll make it so :)

[OwsleyJr]

I'm fine with either of the above, @OwsleyJr if you could pass your verdict on whichever you prefer, I'll make it so :)

We might need further input from @sct before going ahead due to this being a big change in the flow.

[thempc]

It's been about a month at this point. Please decide to accept this or not. If it's not wanted that's fine but I'm not one to keep going after open source changes months after a pull request has been made.

[actuallyevan]

This would be awesome if merged!!!!

[engels74]

Hey everyone.

For any of you who're still following this pull request, eagerly waiting for it to get merged, I went ahead and created a docker image with this PR included in it, based of the latest release as of this writing (v1.33.2).

It's based on hotio's docker container, and it auto updates and so on and so forth, like the rest of hotio's container images. So if you're familiar with his docker images, it should be a no-brainer to get it up and running. I added a small README to the page, that should explain the basics.

The Docker image can be found here:
https://github.com/engels74/overseerr-anime

I haven't tested it very extensively, but it should work, as it's based off of this PR. Be wary it might not work well with request-bots like requestrr and doplarr.

Kind regards,
engels74

Edit (16/04/2025):
Do not use :nightly unless you are sure what you are doing, refer to the latest update:
#3664 (comment)

:latest or :release should still work for a while, but I'm probably depreacting / removing the :nightly branch for now

[jordanlambrecht]

@sct @engels74 @OwsleyJr Any idea what else still needs to be done to get this merged? Happy to help out wherever needed.

[engels74]

@sct @engels74 @OwsleyJr Any idea what else still needs to be done to get this merged? Happy to help out wherever needed.

All maintainers are very busy, so it probably won't get merged in the near future 🙂

[actuallyevan]

@sct @engels74 @OwsleyJr Any idea what else still needs to be done to get this merged? Happy to help out wherever needed.

Just use @engels74's docker image, it's working great

[Dental1347]

Hey everyone.

For any of you who're still following this pull request, eagerly waiting for it to get merged, I went ahead and created a docker image with this PR included in it, based of the latest release as of this writing (v1.33.2).

It's based on hotio's docker container, and it auto updates and so on and so forth, like the rest of hotio's container images. So if you're familiar with his docker images, it should be a no-brainer to get it up and running. I added a small README to the page, that should explain the basics.

The Docker image can be found here: https://github.com/engels74/overseerr-anime

I haven't tested it very extensively, but it should work, as it's based off of this PR. Be wary it might not work well with request-bots like requestrr and doplarr.

Kind regards, engels74

Regarding the requestrr and doplarr bots, what could cause it to not work? Has this been tested?

Would love to use this, but I also make use of those two bots :)

[engels74]

Regarding the requestrr and doplarr bots, what could cause it to not work? Has this been tested?

Would love to use this, but I also make use of those two bots :)

I haven't tested it really, but looking through the file changes in this PR, you can see there's a new isAnime variable/function. Both requestrr and doplarr is not updated for this. And they probably won't be, until this PR has been merged into the official repository.

What this means in practice is that the bots will probably "work", until a user request an Anime series or movie. I'm not sure what will happen, but most likely it'll either error out, or place the Anime series or movie in an incorrect folder.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[engels74]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Not stale.

[kevindd992002]

Not stale at all. Everyone is waiting for this. Let's keep this going please.

[Isolaryn]

Same, waiting on this.

[samuel-barkley]

We are indeed waiting 😄

[OnniSaarni]

+1 Would love to see this feature merged. I'll try Engels dockers. Cheers!

[actuallyevan]

For everyone in this thread, Redirecterr may provide the functionality you are looking for and is more customizable than engel's image. At the cost of slightly more configuration, it allows you to route requests to instance(s) based on language, type, and other filters. The only compromise is that the admin account cannot make use of the auto-redirection (due to their elevated perms), so you'll have to make a local account for yourself.

[OnniSaarni]

@actuallyevan thank you so much <3

[engels74]

Just a quick update for everyone using my overseerr-anime image:
The nightly branch, which usually tracks "sct/overseerr"’s develop branch, is no longer being actively updated or tested. Please be aware that the :nightly version is now very experimental and may not work as expected.

I will be deprecating / removing the :nightly branch shortly.

The changes upstream have become too complex for me to keep up with, and merging them now goes well beyond what I’m able to handle as a maintainer of just the Docker image. I did my best to manually merge things using the current PR, but at this point, I’d need @thempc to update the PR to the latest commit on the develop branch to ensure everything works. I completely understand if that’s not possible, since this PR is now about 1½ years old 😫.

For now, I recommend sticking with the :latest or :release tag, which is based on Overseerr v1.34.0, if you’re still using the Docker image.

[thempc]

@engels74 I'm indeed using your latest tag ever since you made the image, thanks!

I won't be updating the PR indeed, there seem to be two good alternatives here:

• Use Redirecterr as actuallyeven mentioned.
• Use Jellyseer, jellyseer devs reached out about this PR and are integrating it into Jellyseer here: feat: Adding anime specific Sonarr/Radarr instance support seerr-team/seerr#1522 which I think I will switch to as soon as it's merged.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[keliansb]

Not stale

[impishlucy]

MY BROTHER IN CHRIST ITS BEEN A YEAR @sct

[taylormock03]

@Lozoni overseer is being migrated to seer (https://github.com/seerr-team/seerr). This means that this project will become deprecated and all future updates will be there. At the moment they are doing a change freeze on the repo until it has a stable release. I believe that there is a similar pr that is almost ready to be merged once feature updates are enabled

[engels74]

For anyone interested:

The seerr version of this PR is located here: seerr-team/seerr#1522