Sonarr V4 support

[quorn23]

Description

Currentlyy Jellyseerr isn't working with Sonarr V4.
This is an early request as V4 is in development.

sonarr:v4 tag available
https://github.com/hotio/sonarr/pkgs/container/sonarr

Desired Behavior

Being able to add a Sonarr V4 instance to Jellyseerr as well.

Additional Context

No response

Code of Conduct

• I agree to follow Overseerr's Code of Conduct

[hosaka]

Sonarr v4 has no Language Profiles. The rest of the API should be the same. Perhaps having a Sonarr Version dropdown and not trying to get language profiles when v4 is selected would suffice? I can help with some initial support for this.

[Fallenbagel]

Sonarr v4 is now supported on jellyseerr/overseerr. Specifically Sonarr V4.0.0.205

[hosaka]

Thank you, working with jellyseerr 1.2.1 and sonarr v4.0.0.240

[quorn23]

@Fallenbagel just be aware, the compatibility is due of back porting the endpoints. This is only a temporary fix, as Overseerr (and to that extend) Jellyseerr aren't supporting V4 (yet). It's still deprecated and still needs a proper fix.

[Fallenbagel]

@Fallenbagel just be aware, the compatibility is due of back porting the endpoints. This is only a temporary fix, as Overseerr (and to that extend) Jellyseerr aren't supporting V4 (yet). It's still deprecated and still needs a proper fix.

The only thing is the language profile that's breaking the connection. So nothing to be too much scared about going on from here

[angrycuban13]

You should look at properly supporting V4 and not relying on a fix from Qstick to get some third party applications working. Besides, continuing to use deprecated endpoints creates unnecessary warnings on Sonarr event logs that something is using a deprecated endpoint.

[bakerboy448]

Hitting an endpoint that is depreciated - and thus likely to be removed eventually - and not fixing it doesn't really make logical sense nor does it fix the issue.

All closing this does is kicks the can down the road where eventually the same issue will occur and Sonarr won't be supported.

@hosaka an API version endpoint has been added; or status also has the version as well. either one would allow V4 to be determined and to skip trying to use language profiles in v4 given this is not fixed and is closed in error.

[hosaka]

@bakerboy448 Yeah I gathered that this is not "support for v4" from seeing "deprecated" language profile and no relevant commits on the develop branch, but it does make sonarr usable for the time being. I'm a bit confused about where the development is happening. Is the plan for jellyseerr to eventually merge this from upstream overseerr or PRs will be accepted in this repo?

[Fallenbagel]

@bakerboy448 Yeah I gathered that this is not "support for v4" from seeing "deprecated" language profile and no relevant commits on the develop branch, but it does make sonarr usable for the time being. I'm a bit confused about where the development is happening. Is the plan for jellyseerr to eventually merge this from upstream overseerr or PRs will be accepted in this repo?

For overseerr specific feature like sonarr v4, we would like the PR to go upstream so we can merge from there

[pikeas]

How is full support for Sonarr v4 - and especially the change to Language Profile - coming along?

[Fallenbagel]

How is full support for Sonarr v4 - and especially the change to Language Profile - coming along?

Afaik, language profile is now handled by custom formats and is completely deprecated. We are keeping the option for just legacy support. You should be handling the languages through custom formats.

[Fallenbagel]

🎉 This issue has been resolved in version 2.1.0 🎉

The release is available on:

• v2.1.0
• GitHub release

Your semantic-release bot 📦🚀