Description

Hi,

as of a recent update, the request handling and interaction for 4k/non-4k requests was changed. I did not find the exact commit, but observed that new behaviour rather recently. I also reported it in Discord. After that, I tested around a bit more.

My setup includes a 4k and a non-4k instance for both Radarr and Sonarr. They are properly configured, the requests are going to the respective instance depending on request type. Everything is running in Debian 12.

The change improved the scanning behavior, making Jellyseerr's availability definition based on the width of Media that it gets from Jellyfin. That makes sense, but causes issues with setups like mine that use separate 4k and non-4k instances.

• The request that initially has no 4k available and is marked on Jellyseerr as "4k Deleted" still IS on the 4k Radarr/Sonarr instance. If I requested something in 4k, but it wasn't available in 4k for some reason, it will then be counted as non-4k in Jellyseerr, marked as "Available" as well. The issue with that - users that do not have 4k request permissions and also no 4k viewing permissions in Jellyfin will now see this Media as "Available", but it is not visible in their library because the Media only exists in the 4k folder. Users also cannot request it in non-4k anymore.
• Before the change, that was a non-issue. It was only marked as "4k Available", which was irrelevant for anyone who only has non-4k permissions, and could have been requested as non-4k.
• I sometimes request things in 4k, knowing that they will get a 4k release eventually, usually because it was announced. That means that the existing 1080p versions will be pulled and later upgraded to 2160p. E.g., there is Media that was released as 1080p in Streaming Services, but will get a Bluray release in 2160p. I did request it in 4k a while ago, and logically, it only could be pulled in 1080p. With the QP https://trash-guides.info/Sonarr/sonarr-setup-quality-profiles-german-en/#uhd-bluray-web-2160p using the "Alternative Quality Profile", as soon as the 2160p release is available, it will be upgraded.
• One could argue to always request it in non-4k first as well, or argue that one should only use a QP that does not allow lower resolutions and then still request it in non-4k - well, users might want to watch the Media before it gets the 2160p upgrade already, but don't want to keep a 1080p copy as soon as the quality upgrade is available. Of course you could manage that manually, but that defeats the point - the entire aim of software such as Jellyseerr is automation.

I'd propose the following points as ideas:

1. A setting to toggle the detection behavior. Let the Administrator decide whether they want Jellyseerr to only respect the initial input (was it sent to a non-4k or a 4k instance?) or whether they want Jellyseerr to smartly handle it using width data from Jellyfin.
2. A setting to automatically cancel the 4k request if a non-4k file was pulled, remove the request and file from the 4k instance and re-request it in non-4k (sending it to the non-4k instance). In the end, the affected Media could be marked as "Available"=Green and "4k not found"=Yellow (the latter being visible only for users with 4k permissions). In this scenario, "4k" can be requested again.
3. A setting to automatically request Media in non-4k as well if a non-4k file was pulled, send a new Request to the non-4k instance and keep the non-4k of the 4k instance. In the end, the affected Media could be marked as "Available"=Green and "4k monitoring for Upgrade"=Yellow (the latter being visible only for users with 4k permissions). In this scenario, there is no need to Request anything again. As soon as the non-4k Media on the 4k instance is finally upgraded to 4k, it will simply be marked as "4k Available"=Green.
4. Simply do not mark Media as "Available" if the 4k instance has a non-4k version. This allows non-4k users to still request it in non-4k, being unaffected by this. Give it the marking "4k not found"=Yellow or maybe even better, "4k monitoring for Upgrade"=Yellow. Former tag if the admin decides to delete 4k Request if nothing was found (without automatically Requesting it in non-4k), the latter if the admin decides to keep the 4k Request, but does not want a non-4k Request to be sent (see previous bullet points for reference).
5. "Deleted"=Red and "4k Deleted"=Red should be reserved for cases where a file was actually deleted.

With kind regards

Version

2.7.0

Steps to Reproduce

Previous behavior:

1. Request media in 4k
2. If media could be found in 4k, it is marked as "4k Available". It will be saved in the 4k library as configured.
3. If media could not be found in 4k but in non-4k instead, it is also marked as "4k Available". It will be saved in the 4k library as configured. However, it could still be requested as non-4k, ensuring that users that only have access to the non-4k library can still request it.
4. If media becomes available in 4k, it will be upgraded as per https://trash-guides.info/Sonarr/sonarr-setup-quality-profiles-german-en/#uhd-bluray-web-2160p using the "Alternative Quality Profile". Markings remain as "4k Available".

Current behavior:

1. Request media in 4k
2. If media could be found in 4k, it is marked as "4k Available". It will be saved in the 4k library as configured.
3. If media could not be found in 4k but in non-4k instead, it is now marked as "4k Deleted". It will be saved in the 4k library as configured. However, Jellyseerr then also marks it as "Available", denying the possibility to properly Request it in non-4k, but it allows requesting in 4k, causing conflicts. The media will not be requestable or visible for non-4k users regardless.
4. If media finally becomes available in 4k, it will be upgraded as per https://trash-guides.info/Sonarr/sonarr-setup-quality-profiles-german-en/#uhd-bluray-web-2160p using the "Alternative Quality Profile". Markings are now changed to "Deleted" and "4k Available". This allows users to request in non-4k again, but is also misleading.

Screenshots

No response

Logs

Platform

desktop

Database

SQLite (default)

Device

Any

Operating System

Any

Browser

Any

Additional Context

No response

Code of Conduct

• I agree to follow Jellyseerr's Code of Conduct