Accept/Reject releases based on indexer's release attributes

deekerman commented

2026-02-20 05:03:33 -05:00

Owner

Originally created by @jordandrako on GitHub (Oct 21, 2018).

Describe the problem
Some indexers, such as HDBits, support tags on their releases. It would be great if we could specify required tags in the indexer settings like Radarr does so we can avoid grabbing releases that will unnecessarily increase seed ratios. General support would be great, but I'm specifically looking for HDBits internal tags to be supported as a requirement before grabbing.

Describe any solutions you think might work
Here is some documentation on the tags Radarr supports: https://github.com/Radarr/Radarr/wiki/Indexer-Flags#1-required-flags

Additional context
These tags can also be used as a preference to grab freeleech or golden popcorn over other encodes. I've searched the issues and can't find anything related specifically to indexer tags, just sonarr tags in the restrictions which aren't the same: they require the required term to be in the release name. Indexer tags are part of the indexer's api as far as I know.

Originally created by @jordandrako on GitHub (Oct 21, 2018). **Describe the problem** Some indexers, such as HDBits, support tags on their releases. It would be great if we could specify required tags in the indexer settings like Radarr does so we can avoid grabbing releases that will unnecessarily increase seed ratios. General support would be great, but I'm specifically looking for HDBits internal tags to be supported as a requirement before grabbing. **Describe any solutions you think might work** Here is some documentation on the tags Radarr supports: https://github.com/Radarr/Radarr/wiki/Indexer-Flags#1-required-flags **Additional context** These tags can also be used as a preference to grab freeleech or golden popcorn over other encodes. I've searched the issues and can't find anything related specifically to indexer tags, just sonarr tags in the restrictions which aren't the same: they require the required term to be in the release name. Indexer tags are part of the indexer's api as far as I know.

deekerman

2026-02-20 05:03:33 -05:00

closed this issue
added the
enhancement

proposal

indexer
labels

deekerman commented

2026-02-20 05:03:34 -05:00

Author

Owner

@jordandrako commented on GitHub (Oct 21, 2018):

Also, here is how Jackett handles it (I think): github.com/Jackett/Jackett@060972475f/src/Jackett.Common/Definitions/hdbits.yml (L73)

@jordandrako commented on GitHub (Oct 21, 2018): Also, here is how Jackett handles it (I think): https://github.com/Jackett/Jackett/blob/060972475f13ffe59fcc09c51ffe91a547a29029/src/Jackett.Common/Definitions/hdbits.yml#L73

deekerman commented

2026-02-20 05:03:34 -05:00

Author

Owner

@markus101 commented on GitHub (Oct 21, 2018):

Wouldn't Internal be part of the release name?

Something like additional parameters could be used to exclude releases if they can be filtered on HDBit's side, but I don't see a good way to translate "tags" on the indexer to specific restrictions within Sonarr and I don't think it makes a lot of sense to attempt it for a single indexer.

@markus101 commented on GitHub (Oct 21, 2018): Wouldn't `Internal` be part of the release name? Something like additional parameters could be used to exclude releases if they can be filtered on HDBit's side, but I don't see a good way to translate "tags" on the indexer to specific restrictions within Sonarr and I don't think it makes a lot of sense to attempt it for a single indexer.

deekerman commented

2026-02-20 05:03:34 -05:00

Author

Owner

@shauder commented on GitHub (May 24, 2019):

This would be helpful for me also and is useful in Radarr.

@shauder commented on GitHub (May 24, 2019): This would be helpful for me also and is useful in Radarr.

deekerman commented

2026-02-20 05:03:35 -05:00

Author

Owner

@2fst4u commented on GitHub (Jun 3, 2019):

Please support this. Radarr handles this without issue and allows the flag to be shown on the search interface which is really helpful for making sure you grab a release that won't "cost" you.

Radarr can also prioritise entries with flags above ones without flags.

Same as OP, I'd like to be able to tell Sonarr to only grab torrents if they're freeleech.

@2fst4u commented on GitHub (Jun 3, 2019): Please support this. Radarr handles this without issue and allows the flag to be shown on the search interface which is really helpful for making sure you grab a release that won't "cost" you. Radarr can also prioritise entries with flags above ones without flags. Same as OP, I'd like to be able to tell Sonarr to only grab torrents if they're freeleech.

deekerman commented

2026-02-20 05:03:35 -05:00

Author

Owner

@2fst4u commented on GitHub (Jun 6, 2019):

A further addition to why this would be great:

If you have multiple private trackers with different freeleech parameters, it would be preferable to prioritise one over the other if the same file is freeleech on one but not in another.

For example I have one tracker that makes all releases freeleech for a certain period of time, I would prefer these for brand new releases. I have another tracker that makes all releases over a certain file size freeleech, these would be preferable for older files.

Because my trackers aren't prioritised in any other way for the same file in a search, one of my indexers keeps being used more than the other when I'd like the one with freeleech releases to be used instead.

Jackett parses the freeleech tag correctly for both of these, so it would be super appreciated if it carried through to Sonarr in the same way it does for Radarr.

@2fst4u commented on GitHub (Jun 6, 2019): A further addition to why this would be great: If you have multiple private trackers with different freeleech parameters, it would be preferable to prioritise one over the other if the same file is freeleech on one but not in another. For example I have one tracker that makes all releases freeleech for a certain period of time, I would prefer these for brand new releases. I have another tracker that makes all releases over a certain file size freeleech, these would be preferable for older files. Because my trackers aren't prioritised in any other way for the same file in a search, one of my indexers keeps being used more than the other when I'd like the one with freeleech releases to be used instead. Jackett parses the freeleech tag correctly for both of these, so it would be super appreciated if it carried through to Sonarr in the same way it does for Radarr.

deekerman commented

2026-02-20 05:03:35 -05:00

Author

Owner

@omeryagmurlu commented on GitHub (Jul 6, 2019):

any updates?

@omeryagmurlu commented on GitHub (Jul 6, 2019): any updates?

deekerman commented

2026-02-20 05:03:35 -05:00

Author

Owner

@don4of4 commented on GitHub (May 6, 2020):

Hello all,

This issue is vexing enough that I will happily take up the development if @Taloth
and @markus101 point me in the direction you want to go.

I would propose a focused approach:

Starting with a very simple PR of showing the loadingfactor on the UX, like radarr does.
Then, looking at adding a config option (checkbox) to prefer better loading factors. As a user, I would expect that given a certain quality profile (group), that the best loadingfactor (for download) is preferred. e.g. freeleech is better than half-leech, is better than normal, etc. As a secondary selection, the best uploadloading factor would be selected. (I'm guessing the complexity here is how this all interacts with other preference flags.)
Finally, we can look at (a separate effort) to allow configuration of this behavior, and more significant lifts, like filtering, upload preference, etc.

Related Items:

#3036 -> Incomplete work; probably stalled because it had a wide scope, so looking to take some more bite sized chunks this round.
#1464 -> Adding the torznab attributes. (See also 428107792dfeafbf920da05404ad41920140fa76)
#2138
any others I should look at?

Any guidance is appreciated!

Thank you,
-Don

@don4of4 commented on GitHub (May 6, 2020): Hello all, This issue is vexing enough that I will happily take up the development if @Taloth and @markus101 point me in the direction you want to go. I would propose a focused approach: - _Starting_ with a very simple PR of showing the loadingfactor on the UX, like radarr does. - Then, looking at adding a config option (checkbox) to _prefer_ better loading factors. As a user, I would expect that given a certain quality profile (group), that the best loadingfactor (for download) is preferred. e.g. freeleech is better than half-leech, is better than normal, etc. As a secondary selection, the best uploadloading factor would be selected. _(I'm guessing the complexity here is how this all interacts with other preference flags.)_ - Finally, we can look at (a separate effort) to allow configuration of this behavior, and more significant lifts, like filtering, upload preference, etc. Related Items: - #3036 -> Incomplete work; probably stalled because it had a wide scope, so looking to take some more bite sized chunks this round. - #1464 -> Adding the torznab attributes. (See also [428107792dfeafbf920da05404ad41920140fa76](https://github.com/rlightner/Sonarr/commit/428107792dfeafbf920da05404ad41920140fa76)) - #2138 - _any others I should look at?_ Any guidance is appreciated! Thank you, -Don

deekerman commented

2026-02-20 05:03:35 -05:00

Author

Owner

@ericvlog commented on GitHub (Dec 27, 2020):

When sonarr will update this? It very important for us no using usenet.

@ericvlog commented on GitHub (Dec 27, 2020): When sonarr will update this? It very important for us no using usenet.

deekerman commented

2026-02-20 05:03:35 -05:00

Author

Owner

@batuhankrmn commented on GitHub (May 11, 2021):

I don't want to be disrespectful, I am completely grateful for your work, just wonder: Radarr already has provided this feature very nicely and the same feature has been requested by Sonarr users over and over. A user has even stated above that he is willing to help with the development part.

I am looking forward to this feature that will significantly improve the user experience. It would be nice if we could at least get an update from the developers on this feature. Even if we find out whether there is a positive or negative planning about this feature, it will be enough.

@batuhankrmn commented on GitHub (May 11, 2021): I don't want to be disrespectful, I am completely grateful for your work, just wonder: Radarr already has provided this feature very nicely and the same feature has been requested by Sonarr users over and over. A user has even stated above that he is willing to help with the development part. I am looking forward to this feature that will significantly improve the user experience. It would be nice if we could at least get an update from the developers on this feature. Even if we find out whether there is a positive or negative planning about this feature, it will be enough.

deekerman commented

2026-02-20 05:03:35 -05:00

Author

Owner

@Taloth commented on GitHub (May 15, 2021):

You're not wrong. tbh I have no idea what happened around May last year. I sometimes just mark all github notification email as read. 😄 Sometimes I read while at work and promptly forget about it after work. :shrugs:

Anyway, I think the approach remains an extension of #3036, which is effectively merged into sonarr v3 over a year ago, but I've been keeping it alive since it contains all the follow up discussions.
The idea was that we first needed indexer specific filtering and some foundational work. There's a lengthy discussion about it in that PR.
There are two approaches there:

tag:freeleech preferred word. The idea is that the logic should support prefixes such as tag: origin: group: kinda how the current ones are effectively defaulted to title:. Crux here is that I want autocompletion in the UI to expose the prefixes and possible values.
Problem here is that preferred words do 'upgrades', which means it could decide to prefer to upgrade to a freeleech torrent. Something you don't want. But I seem to recall that we want to add a checkbox to Release Profiles to prevent it from being considered in upgrades, which would 'fix' it, but I fear many users will misconfigure that.
'Prefer freeleech' checkbox. This would mean that downloadvolumefactor would be considered, so 0 > 0.5 > 1.0. Challenge here is to decide where in the sort to do this. It's damned if you do, damned if you don't, coz most ppl will want preferred words to be prioritized over freeleech, but some might the other way around. Anyway, I think it should sit below CompareProtocol.

As for 'when', my 'high priority' list is fairly lengthy. Let's just say that when you have to focus writing code at work for weeks due to deadlines, you don't want to spend your evenings writing code too. 😅

@Taloth commented on GitHub (May 15, 2021): You're not wrong. tbh I have no idea what happened around May last year. I sometimes just mark all github notification email as read. :smile: Sometimes I read while at work and promptly forget about it after work. :shrugs: Anyway, I think the approach remains an extension of #3036, which is effectively merged into sonarr v3 over a year ago, but I've been keeping it alive since it contains all the follow up discussions. The idea was that we first needed indexer specific filtering and some foundational work. There's a lengthy discussion about it in that PR. There are two approaches there: 1. `tag:freeleech` preferred word. The idea is that the logic should support prefixes such as `tag:` `origin:` `group:` kinda how the current ones are effectively defaulted to `title:`. Crux here is that I want autocompletion in the UI to expose the prefixes and possible values. Problem here is that preferred words do 'upgrades', which means it could decide to prefer to upgrade to a freeleech torrent. Something you don't want. But I seem to recall that we want to add a checkbox to Release Profiles to prevent it from being considered in upgrades, which would 'fix' it, but I fear many users will misconfigure that. 2. 'Prefer freeleech' checkbox. This would mean that downloadvolumefactor would be considered, so 0 > 0.5 > 1.0. Challenge here is to decide [where in the sort](https://github.com/Sonarr/Sonarr/blob/develop/src/NzbDrone.Core/DecisionEngine/DownloadDecisionComparer.cs#L31-L40) to do this. It's damned if you do, damned if you don't, coz most ppl will want preferred words to be prioritized over freeleech, but some might the other way around. Anyway, I think it should sit below CompareProtocol. As for 'when', my 'high priority' list is fairly lengthy. Let's just say that when you have to focus writing code at work for weeks due to deadlines, you don't want to spend your evenings writing code too. 😅

deekerman commented

2026-02-20 05:03:35 -05:00

Author

Owner

@batuhankrmn commented on GitHub (May 15, 2021):

You're not wrong. tbh I have no idea what happened around May last year. I sometimes just mark all github notification email as read. 😄 Sometimes I read while at work and promptly forget about it after work. :shrugs:

Anyway, I think the approach remains an extension of #3036, which is effectively merged into sonarr v3 over a year ago, but I've been keeping it alive since it contains all the follow up discussions.
The idea was that we first needed indexer specific filtering and some foundational work. There's a lengthy discussion about it in that PR.
There are two approaches there:

tag:freeleech preferred word. The idea is that the logic should support prefixes such as tag: origin: group: kinda how the current ones are effectively defaulted to title:. Crux here is that I want autocompletion in the UI to expose the prefixes and possible values.
Problem here is that preferred words do 'upgrades', which means it could decide to prefer to upgrade to a freeleech torrent. Something you don't want. But I seem to recall that we want to add a checkbox to Release Profiles to prevent it from being considered in upgrades, which would 'fix' it, but I fear many users will misconfigure that.

'Prefer freeleech' checkbox. This would mean that downloadvolumefactor would be considered, so 0 > 0.5 > 1.0. Challenge here is to decide where in the sort to do this. It's damned if you do, damned if you don't, coz most ppl will want preferred words to be prioritized over freeleech, but some might the other way around. Anyway, I think it should sit below CompareProtocol.

As for 'when', my 'high priority' list is fairly lengthy. Let's just say that when you have to focus writing code at work for weeks due to deadlines, you don't want to spend your evenings writing code too. 😅

Here is one idea, might be stupid tho: If Sonarr can reference and support the Custom Formats feature from Radarr, It'd be super great since most of Sonarr users also use Radarr too. So they are already familiar with the Custom Formats, It wont be a problem to figure out settings. Also custom formats offers much more than just freeleech. When I saw Radarr's custom formats, I was like "damn, this is the ultimate customization!". Has Custom Format support for Sonarr ever been considered?

@batuhankrmn commented on GitHub (May 15, 2021): > You're not wrong. tbh I have no idea what happened around May last year. I sometimes just mark all github notification email as read. 😄 Sometimes I read while at work and promptly forget about it after work. :shrugs: > > Anyway, I think the approach remains an extension of #3036, which is effectively merged into sonarr v3 over a year ago, but I've been keeping it alive since it contains all the follow up discussions. > The idea was that we first needed indexer specific filtering and some foundational work. There's a lengthy discussion about it in that PR. > There are two approaches there: > > 1. `tag:freeleech` preferred word. The idea is that the logic should support prefixes such as `tag:` `origin:` `group:` kinda how the current ones are effectively defaulted to `title:`. Crux here is that I want autocompletion in the UI to expose the prefixes and possible values. > Problem here is that preferred words do 'upgrades', which means it could decide to prefer to upgrade to a freeleech torrent. Something you don't want. But I seem to recall that we want to add a checkbox to Release Profiles to prevent it from being considered in upgrades, which would 'fix' it, but I fear many users will misconfigure that. > 2. 'Prefer freeleech' checkbox. This would mean that downloadvolumefactor would be considered, so 0 > 0.5 > 1.0. Challenge here is to decide [where in the sort](https://github.com/Sonarr/Sonarr/blob/develop/src/NzbDrone.Core/DecisionEngine/DownloadDecisionComparer.cs#L31-L40) to do this. It's damned if you do, damned if you don't, coz most ppl will want preferred words to be prioritized over freeleech, but some might the other way around. Anyway, I think it should sit below CompareProtocol. > > As for 'when', my 'high priority' list is fairly lengthy. Let's just say that when you have to focus writing code at work for weeks due to deadlines, you don't want to spend your evenings writing code too. 😅 Here is one idea, might be stupid tho: If Sonarr can reference and support the Custom Formats feature from Radarr, It'd be super great since most of Sonarr users also use Radarr too. So they are already familiar with the Custom Formats, It wont be a problem to figure out settings. Also custom formats offers much more than just freeleech. When I saw Radarr's custom formats, I was like "damn, this is the ultimate customization!". Has Custom Format support for Sonarr ever been considered?

deekerman commented

2026-02-20 05:03:35 -05:00

Author

Owner

@neo-neo1 commented on GitHub (Nov 9, 2021):

Any current plans to add this? Been 3 years since Radarr has it. Is it possible to adopt the same code?

@neo-neo1 commented on GitHub (Nov 9, 2021): Any current plans to add this? Been 3 years since Radarr has it. Is it possible to adopt the same code?

deekerman commented

2026-02-20 05:03:35 -05:00

Author

Owner

@Mavyre commented on GitHub (Nov 21, 2022):

Up'ing this issue, as this would be awesome to have it like Radarr. In Radarr, that really helps a lot to have a semi-automatic download without impacting the ratio for automatic downloads.

@Mavyre commented on GitHub (Nov 21, 2022): Up'ing this issue, as this would be awesome to have it like Radarr. In Radarr, that really helps a lot to have a semi-automatic download without impacting the ratio for automatic downloads.

deekerman commented

2026-02-20 05:03:35 -05:00

Author

Owner

@cybersteel8 commented on GitHub (Jun 8, 2023):

Sadly this doesn't still seem to be a feature. I set up private trackers in Radarr successfully, and I was looking for the Required Flags section in the indexer screen here in Sonarr, but it looks like it's a completely missing feature in Sonarr.

The only workaround right now is to hopefully be able to refer to your indexer flags in the indexer itself (eg. Jackett). However this is global for all your *arr applications, if they all refer to the same Jackett instance.

This is a glaring omission from a codebase that I thought was extremely similar to Radarr. I would really like to see this get added, and based on the age of this feedback and suggestions I've seen on the forums and suggestion site, it's been wanted for years. Let's make it happen.

@cybersteel8 commented on GitHub (Jun 8, 2023): Sadly this doesn't still seem to be a feature. I set up private trackers in Radarr successfully, and I was looking for the Required Flags section in the indexer screen here in Sonarr, but it looks like it's a completely missing feature in Sonarr. The only workaround right now is to hopefully be able to refer to your indexer flags in the indexer itself (eg. Jackett). However this is global for all your *arr applications, if they all refer to the same Jackett instance. This is a glaring omission from a codebase that I thought was extremely similar to Radarr. I would really like to see this get added, and based on the age of this feedback and suggestions I've seen on the forums and suggestion site, it's been wanted for years. Let's make it happen.

deekerman commented

2026-02-20 05:03:36 -05:00

Author

Owner

@Sdhb1 commented on GitHub (Dec 22, 2023):

Upping this longstanding issue. Would be fantastic to implement free leech tag exactly as radarr has done. TY!

@Sdhb1 commented on GitHub (Dec 22, 2023): Upping this longstanding issue. Would be fantastic to implement free leech tag exactly as radarr has done. TY!

deekerman commented

2026-02-20 05:03:36 -05:00

Author

Owner

@neo-neo1 commented on GitHub (Dec 22, 2023):

Upping this longstanding issue. Would be fantastic to implement free leech tag exactly as radarr has done. TY!

We can only dream at this point

@neo-neo1 commented on GitHub (Dec 22, 2023): > Upping this longstanding issue. Would be fantastic to implement free leech tag exactly as radarr has done. TY! We can only dream at this point

deekerman commented

2026-02-20 05:03:36 -05:00

Author

Owner

@Sdhb1 commented on GitHub (Dec 22, 2023):

Upping this longstanding issue. Would be fantastic to implement free leech tag exactly as radarr has done. TY!

We can only dream at this point

Curious as to why this hasn't been prioritized. I would have thought this feature would be a "must have" for anyone using private trackers where ratio can be a concern. Is there some other way users manage this currently?

@Sdhb1 commented on GitHub (Dec 22, 2023): > > Upping this longstanding issue. Would be fantastic to implement free leech tag exactly as radarr has done. TY! > > We can only dream at this point Curious as to why this hasn't been prioritized. I would have thought this feature would be a "must have" for anyone using private trackers where ratio can be a concern. Is there some other way users manage this currently?

deekerman commented

2026-02-20 05:03:36 -05:00

Author

Owner

@Theetjuh commented on GitHub (Dec 25, 2023):

I was actually surprised it wasn’t implemented yet, since Radarr has it right there.

Would love an indexer flag like Radarr has so I can prefer freeleech.

@Theetjuh commented on GitHub (Dec 25, 2023): I was actually surprised it wasn’t implemented yet, since Radarr has it right there. Would love an indexer flag like Radarr has so I can prefer freeleech.

Rows
Columns

Accept/Reject releases based on indexer's release attributes #2240