Prefer Indexer Flag not working as expected #9271

New issue

Closed

opened 2026-02-20 00:12:20 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-20 00:12:20 -05:00

Owner

Originally created by @deecypher on GitHub (Sep 23, 2025).

Is there an existing issue for this?

I have searched the existing open and closed issues

Current Behavior

According to my review of the DownloadDecisionComparer, Radarr decides what to grab in this order: Quality → CustomFormatScore → Protocol → IndexerPriority → IndexerFlags → PeersIfTorrent → AgeIfUsenet → Size.

In my case, most of the candidates were from the same release group and otherwise identical. Everything compared equally until the process reached IndexerFlags. One release had a partial freeleech flag, the others did not.

I have “Prefer Indexer Flags” disabled, so I expected Radarr to ignore the flag and move on to the next variable, peers. Based on that, the torrent with the higher peer count should have been chosen. Instead, Radarr picked the flagged torrent, which suggests that the “Prefer Indexer Flags” setting isn’t being respected.

Expected Behavior

Radarr should ignore the flag when “Prefer Indexer Flags” is disabled.
The tie should be broken by the next comparer variable: peers.
The torrent with the higher peer count should be selected.

Steps To Reproduce

Add at least two indexers that return the same release.
Ensure the releases are identical (same quality, size, etc.), except one has an indexer flag (e.g., partial freeleech).
Disable “Prefer Indexer Flags” in settings.
Trigger an automatic grab via RSS Sync.

Environment

- OS: macOS 15.7
- Radarr: 5.27.5.10198
- Docker Install: n/a
- Using Reverse Proxy: n/a
- Browser: Chrome 140.0.7339.133
- Database: Sqlite 3.36.0

What branch are you running?

Master

Trace Logs? Not Optional

Trace Logs: radarr.trace.txt

Trace Logs have been provided as applicable. Reports will be closed if the required logs are not provided.

I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain trace - that are relevant and show this issue.

Originally created by @deecypher on GitHub (Sep 23, 2025). ### Is there an existing issue for this? - [x] I have searched the existing open and closed issues ### Current Behavior According to my review of the DownloadDecisionComparer, Radarr decides what to grab in this order: Quality → CustomFormatScore → Protocol → IndexerPriority → IndexerFlags → PeersIfTorrent → AgeIfUsenet → Size. In my case, most of the candidates were from the same release group and otherwise identical. Everything compared equally until the process reached IndexerFlags. One release had a partial freeleech flag, the others did not. I have “Prefer Indexer Flags” disabled, so I expected Radarr to ignore the flag and move on to the next variable, peers. Based on that, the torrent with the higher peer count should have been chosen. Instead, Radarr picked the flagged torrent, which suggests that the “Prefer Indexer Flags” setting isn’t being respected. ### Expected Behavior 1. Radarr should ignore the flag when “Prefer Indexer Flags” is disabled. 2. The tie should be broken by the next comparer variable: peers. 3. The torrent with the higher peer count should be selected. ### Steps To Reproduce 1. Add at least two indexers that return the same release. 2. Ensure the releases are identical (same quality, size, etc.), except one has an indexer flag (e.g., partial freeleech). 3. Disable “Prefer Indexer Flags” in settings. 4. Trigger an automatic grab via RSS Sync. ### Environment ```markdown - OS: macOS 15.7 - Radarr: 5.27.5.10198 - Docker Install: n/a - Using Reverse Proxy: n/a - Browser: Chrome 140.0.7339.133 - Database: Sqlite 3.36.0 ``` ### What branch are you running? Master ### Trace Logs? **Not Optional** Trace Logs: [radarr.trace.txt](https://github.com/user-attachments/files/22489787/radarr.trace.txt) <img width="1189" height="730" alt="Image" src="https://github.com/user-attachments/assets/b406b175-e054-4172-b0c0-1984c560f062" /> ### Trace Logs have been provided as applicable. Reports will be closed if the required logs are not provided. - [x] I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain `trace` - that are relevant and show this issue.

deekerman

2026-02-20 00:12:20 -05:00

closed this issue
added the
Type: Bug

Status: Won't Fix
labels

deekerman commented

2026-02-20 00:12:21 -05:00

Author

Owner

@mynameisbogdan commented on GitHub (Sep 23, 2025):

The setting works as intended, but the seeders and peers are sorted using rounded log10 values so it's not always the bigger value wins. Meaning any seeders between 32 and 316 would be counted as 2, thus all your releases from the search would have the same priority in this regard.

Also you sorted by peers in the screenshot, which is not the default sorting that Radarr uses for download ranking.

@mynameisbogdan commented on GitHub (Sep 23, 2025): The setting works as intended, but the seeders and peers are sorted using rounded log10 values so it's not always the bigger value wins. Meaning any seeders between 32 and 316 would be counted as 2, thus all your releases from the search would have the same priority in this regard. Also you sorted by peers in the screenshot, which is not the default sorting that Radarr uses for download ranking.