You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the existing open and closed issues
Is your feature request related to a problem? Please describe
I use a custom format to add a +1 score to any release that has a freeleech flag, so that if multiple indexers have the same release, Radarr will always grab it from an indexer that has it freeleech, if any.
Here is the issue that can arise from this method.
Let's say Radarr searches for a movie and grabs a release from RlsGroupA, with a score of 1000. Multiple indexers have that release but none of them have it freeleech.
Later on, an indexer releases the same movie by RlsGroupB, which by default has the same CF score as RlsGroupA (1000); however, this release is freeleech, so it will get the CF bonus and have a score of 1001. Radarr will thus see it as an upgrade from the previously grabbed release by RlsGroupA and replace it, even though both RlsGroup are otherwise treated as equivalent and shouldn't be considered upgrades from one another.
Describe the solution you'd like
I realize that what I describe above is Radarr working as intended, but I believe Radarr could benefit from a tweak that could resolve this issue without fundamentally impacting how upgrades work.
I think it could be nice to have the ability to set a minimum step in score upgrades before Radarr considers one release an upgrade from another. For instance, in the situation described above, I could tell Radarr to only consider upgrading a release if another one gets a CF score of at least 5 more points; i.e., the release from RlsGroupA with a CF score of 1000 wouldn't be upgraded by the release from RlsGroupB with its CF score of 1001, but it would get an upgrade from a release by RlsGroupC that has a score of 1005 or above.
Describe alternatives you've considered
I can't think of any alternative that doesn't involve giving up on the freeleech CF method.
Anything else?
No
The text was updated successfully, but these errors were encountered:
Is there an existing issue for this?
Is your feature request related to a problem? Please describe
I use a custom format to add a +1 score to any release that has a freeleech flag, so that if multiple indexers have the same release, Radarr will always grab it from an indexer that has it freeleech, if any.
Here is the issue that can arise from this method.
Let's say Radarr searches for a movie and grabs a release from RlsGroupA, with a score of 1000. Multiple indexers have that release but none of them have it freeleech.
Later on, an indexer releases the same movie by RlsGroupB, which by default has the same CF score as RlsGroupA (1000); however, this release is freeleech, so it will get the CF bonus and have a score of 1001. Radarr will thus see it as an upgrade from the previously grabbed release by RlsGroupA and replace it, even though both RlsGroup are otherwise treated as equivalent and shouldn't be considered upgrades from one another.
Describe the solution you'd like
I realize that what I describe above is Radarr working as intended, but I believe Radarr could benefit from a tweak that could resolve this issue without fundamentally impacting how upgrades work.
I think it could be nice to have the ability to set a minimum step in score upgrades before Radarr considers one release an upgrade from another. For instance, in the situation described above, I could tell Radarr to only consider upgrading a release if another one gets a CF score of at least 5 more points; i.e., the release from RlsGroupA with a CF score of 1000 wouldn't be upgraded by the release from RlsGroupB with its CF score of 1001, but it would get an upgrade from a release by RlsGroupC that has a score of 1005 or above.
Describe alternatives you've considered
I can't think of any alternative that doesn't involve giving up on the freeleech CF method.
Anything else?
No
The text was updated successfully, but these errors were encountered: