Indexer Prioritization about sonarr HOT 30 CLOSED

I think this feature needs to be given a higher priority. It's quite important for many reasons to want to choose some indexers over others.

from sonarr.

This could be implemented via indexer level delays similar to the way the torrents / nzb can be set via delays. I.e. if I prefer indexer A over B I can set a delay on B of 6h so that B is only used if A does not get the show within 6 hours of B getting it. flexget works in a similar way. Flexget works with delays per feed (i.e. indexer) to accomplish the same.

from sonarr.

Comment from erikneff on Trello:

@Keivanbeigi For what it's worth, 2) is exactly what I would like, and is the reason I'm here. The scenario below is what prompted me to google sonarr indexer prioritization, resulting in my finding this page and creating an account just to help clarify for the devs and the community why one user might care about this feature:

SABnzbd+ has a delightfully useful integration with oznzb that auto-pulls and displays user ratings from queued nzbs, putting those ratings right inline with the download in the interface. None of my other indexers support this integration however, so all things being equal, I'd absolutely prefer sonarr to pull nzbs from oz than elsewhere. I've noticed recently that oznzb is rarely getting nzbs pulled from it, even when the exact same release is available in it and other indexers. Not really what Sonarr's decision tree looks like for how it deals with getting multiple answers - maybe it just takes the first answer it gets? Anyways, I'd prefer not to have to disable all other indexes but oz to get the benefit of this sab feature, since having multiple indexes enabled gives a bit better coverage and reliability. I'd just prefer that, all things being equal, oznzb be the source of the nzbs that get queued up.

My $0.01.

from sonarr.

Sorry to butt in, but I'd personally think it'd work best like this.

Sonarr checks the top priority indexer for all releases (typically done due to paid account for one indexer),

1. If top quality releases are found, then queue up the best one and proceed as usual.
2. If quality is not top, then queue up the best release you have in sabnzbd and then add this file to a backlog of files to search for "upgrades" for on other indexers.
3. If release is not found, then immediately search the other providers in priority order.

This would work well if you could specify how many API calls you are allowed with each provider per month so the system could ration out the API calls to alternative indexers based upon urgency.

I'd say it was more urgent to find a release at all than upgrade from SD to HD.

from sonarr.

+1 for this. I would use this as a backup indexer in case my primary feed(s) are down or for some reason the release is not available.

Like add +n minutes/hours delay for the backup indexer, and Sonarr would check that indexer (for example a public rss feed) only +n minutes/hours after. Until then, Sonarr would look at the primary indexer(s) only.

from sonarr.

Comment from markus101 on Trello:

@Keivanbeigi I think #1 would be fairly trivial and puts the onus on the user, #2 would be more difficult to implement, but serves a slightly different purpose.

from sonarr.

Comment from markus101 on Trello:

@erikneff In all likelihood Sonarr is going to interupt that functionality anyways since it pulls the nzb and pushes it to SAB, so SAB doesn't know the source URL anymore. We do it this way to get the ID back from SAB (used for failed/completed download handling).

from sonarr.

Since Sonarr decides which file to push to the download client, I would like to see a priority for otherwise equal releases, since I'm using a mix of torrent and NZB, I would prefer the NZB indexer over the much slower Torrent downloader, a priority could give me that choice, or any other mechanism that makes sense to provide my preference of download client.

from sonarr.

A useful side effect could be you could dequeue releases before they even start if better quality was found elsewhere (assuming you had a backlog of downloads)

from sonarr.

1. Queue in the download client?
2. There is not backlog search in Sonarr: https://github.com/Sonarr/Sonarr/wiki/FAQ#how-does-sonarr-find-episodes

We've discussed it before, not necessarily here, but we're not interested in searching one indexer at a time, but we are considering differentiating between manual and automatic searches and letting users opt out of one or the other: #253

If Sonarr searches and finds something above the cutoff and queues it, it would never upgrade it, even if a higher quality release was on another indexer, but wasn't found because it wasn't searched. We also believe that relying purely on free indexers isn't viable because free indexers that can't cope with the load will die off and we recommend 2-3 solid paid indexers with enough API calls to last through the day for RSS (96 @ 15 minute intervals) + search.

from sonarr.

1. Yes
2. That's exactly my point. I use the free indexers as a last resort. In the event that a release was missing from my paid indexer(s) for whatever reason, i'd like to have the option of checking further afield, however I don't want to overload them with my regular traffic of API calls

from sonarr.

I would love to be able to weight NZB results higher than torrent results. Since I've added some decent torrent based indexers I almost never get downloads via NZB even though I also have quality indexers that are NZB based and have pretty much all the exact same releases ... but I don't want to simply disable the torrent based ones as sometimes I need them, and I certainly don't want to have to constantly toggle them but only if I get things in my wanted list that sit for too long.

from sonarr.

@markus101 Sonarr does not break the rating system. In Sabnzbd+ it automatically submits the rating for bad releases (i.e. Encrypted or missing files.) You can also manually rate the content on oznzb.

from sonarr.

Consider this another request for indexer prioritization. I really would prefer to use my own private RSS feeds first and only fall back to the other indexers if the first (or second, third, etc.) fails.

from sonarr.

I second what @mr-bo-jangles said above. We need to be able to specify last-resort stuff which only gets queried when all else fails.

from sonarr.

+1. One way to go might not be to have a prioritized ranking of indexers, but a way to tag some as favorites. Favorites are searched first. If a match is found, go for it. If not, go to the non-favorites.

Maybe a simpler implementation would just be a switch to prioritize nzb over torrent, which would suit mine and other commenters usage.

from sonarr.

@endquote @Gerk the default is to prioritize usenet over torrents, which you can change via delay profiles. You can also configure a delay to prevent torrents from being grabbed before the usenet releases are even available.

from sonarr.

I'd really love to have this feature as well! Some trackers I have a much higher ratio than others. So, ideally I'd like to prioritize those for downloading older torrents (for auto searches).

It would be nice to not have to disable the less preferred trackers from searching, just in case my first choice doesn't have that particular episode/series.

from sonarr.

Just wanted to add my 2 cents to this.

Personally, the way I would like it is to prioritize quality over tracker, or better yet, have an option. So if tracker A has priority over tracker B but tracker B has a better quality file, it will download from tracker B unless the "quality over tracker" option is on, then it will download the better quality even if the tracker is of lower priority. At a minimum, I think it would be good to implement some sort of private vs public prioritization. I know many people that use public only as a last resort and others that use public more because they don't want their ratio to suffer on private.

from sonarr.

considere it a plus one.
The idea of favorite indexer (and including api call limit!) would work for me.

from sonarr.

After thinking about it more, I think a weighted system is the way to go. With a weighted system the user can assign values to various variables. So you can weight tracker A as 5 and tracker B as 3 meaning tracker A is preferred to tracker B. But you weight 1080p as 5 and 720p as 2. So in this situation tracker A outweighs tracker B but when adding the quality weight, tracker B with 1080p outweighs tracker A with 720p. I think this might be the best solution as you can easily create very complex rules and I don't think it would be too confusing if done well. There can be a display or matrix as you are assigning weights that show the weights added up in various combinations so the user knows exactly what will happen in every possible situation. Maybe even assign the weights to tags so they can be implemented on a per-show basis.

This could also give more granular control over the quality priorities without introducing a lot of complication to the user. For example, one problem I have with the current way qualities are handled is the fact that "quality" varies greatly within and across categories. I have never found a good way to handle this other than manually. For instance, certain release groups have much better quality than others. Also, the web-dl category is going through a lot of changes, what with Hulu and Netflix rips as well as Amazon web-dl being better than iTunes. Normally, my quality priority is 1080pTV<1080pweb-dl<1080pbluray. But DIMENSION releases are usually better than web-dl and sometimes better than the bluray so that screws things up. Then again, sometimes DIMENSION releases are ridiculously huge, like 20gb. Which reminds me, how does Sonarr prioritize size? If there is a web-dl that is 2.2gb and one that is 2.4, which does is download? Anyway, a user could assign values to all these variables: usenet/torrent, tracker, quality, size, even keyword (ex. release group, x265 or the like) or tags. Again, they would have a visual representation of the various combination of weights so they know exactly what will take priority over what. Then Sonarr would download whichever item has the most weight. What do you think about this @markus101? Would that involve too much code change, is there something I am overlooking, am I oversimplifying this, or something else?

from sonarr.

It's way too complex.
Ppl already have a hard time wrapping their head around quality profiles and restrictions/tags. Adding more options should be avoided.
'Weights' are notoriously unpredictable and only potentially benefits a 0.1% of the userbase.

• You can reject the 20gb DIMENSION files via the maxsize criteria per quality.
• User already specifies whether he prefers usenet vs torrents.
• User already specifies which quality is preferred.
• Atm we put torrent seeds, and sizes in buckets. So we don't compare the actual seeds but the order of magnitude. Same for usenet age. buckets of <1h, < 24h, <7days, >7days.

Throwing all these criteria in some pool with some weights makes it harder, if not impossible, to understand. Realise that the option to reorder qualities in the profile is considered an Advanced Setting and already difficult for many to wrap their heads around.

Our current position with regard to indexer prioritization is that IF releases are considered equal by all the above criteria (meaning it's likely the same release), then one indexer might be selected as preferred download source. We don't want too complicated logic nor too many options. It's bad for the average user and it's even worse for us from a support perspective.

from sonarr.

Well, I'm not quite sure I'm articulating it how I mean to or maybe I'm just not considering all the things but the I just wanted to point out a few more things based on your feedback.

"You can reject the 20gb DIMENSION files via the maxsize criteria per quality."

Yep, forgot about that. I was just trying to spitball potential examples.

User already specifies which quality is preferred.

Right but again, there is a lot of inconsistency between and among qualities and there really isn't anything that can be done with that currently. I think it is started to become more of an issue too for the reasons I mentioned earlier. I think a weighted system would help with that and other things.

User already specifies whether he prefers usenet vs torrents.
Ppl already have a hard time wrapping their head around quality profiles and restrictions/tags.

I had a question about that. Say I have my quality set to prefer 1080p over 720p and usenet over torrent. What happens if there is only 720p on usenet but 1080p on torrent? What gets downloaded? I really think this could help with people's understanding because you could have a weight calculator that will give a numerical value to an item. The weight could also show on the manual search page with a breakdown of the weights. Maybe I'm understanding this wrong but right now, you have usenet or torrent as one piece of the "what get's downloaded puzzle", you have quality profiles as another piece, and you have which download to pick based on seeds and size as another piece, and some people now want tracker prioritization as another piece. I think currently it is difficult for users to keep track of how the pieces relate to one another and decide what is downloaded. Maybe I am giving people too much credit but I think if all of these pieces are replaced with one piece, being a weighted system, it would help with users' understand because it would put everything on the same set of rules and give everything an easily understood numerical value. I think ultimately it would actually make things less complex and more flexible.

Realise that the option to reorder qualities in the profile is considered an Advanced Setting and already difficult for many to wrap their heads around.

Maybe it's just me but I think a numerical weight would make it easier for people to wrap their heads around. Changing or adding weights would be an advanced option. I think users would have an easier time understanding the option to reorder qualities with weighted numerical values.

'Weights' are notoriously unpredictable and only potentially benefits a 0.1% of the userbase.
I get that and I very well may be oversimplifying this but that unpredictability might be mitigated in two ways, locked default weights that the average user need not mess with, and a weight calculator that will display example results of any weights added or changed so a user can more accurately predict how their weight changes will work. But I do think it has a greater potential for the userbase beyond this specific issue of prioritizing tracker and gives greater flexibility to users and devs as a weighted system can replace and simplify all those interconnected pieces. So I guess ultimately what I am suggested is somewhat outside the scope of this one issue. I guess I'm not really suggesting adding another option of adding a weight system so much as I am suggesting replacing those various pieces with a weight system. It's probably a pretty big code change as well, I get that, but it's just a suggestion.

Anyway, I hope that makes sense since it was all just kind of a stream of consciousness thing. I don't code very much or very well so I very well may be speaking out of my ass. I'll shut up now.

from sonarr.

Right but again, there is a lot of inconsistency between and among qualities and there really isn't anything that can be done with that currently. I think it is started to become more of an issue too for the reasons I mentioned earlier. I think a weighted system would help with that and other things.

That sounds more like: #385

I had a question about that. Say I have my quality set to prefer 1080p over 720p and usenet over torrent. What happens if there is only 720p on usenet but 1080p on torrent? What gets downloaded?

Quality is king so the 1080p torrent would be grabbed.

The weight could also show on the manual search page with a breakdown of the weights. Maybe I'm understanding this wrong but right now, you have usenet or torrent as one piece of the "what get's downloaded puzzle", you have quality profiles as another piece, and you have which download to pick based on seeds and size as another piece, and some people now want tracker prioritization as another piece. I think currently it is difficult for users to keep track of how the pieces relate to one another and decide what is downloaded. Maybe I am giving people too much credit but I think if all of these pieces are replaced with one piece, being a weighted system, it would help with users' understand because it would put everything on the same set of rules and give everything an easily understood numerical value.

Manual search shows the order Sonarr would attempt to grab the releases in (skipping anything rejected). For a lot of users being able to set things so specifically would be a problem, there are dozens of threads on the forums about things not working and a lot of time it's because the size restrictions were changed or qualities in a profile were dragged around. I think the support increase for such a granular system would be a concern, since time spent on support means we lose time implementing things and fixing bugs.

Your suggestion makes sense, but I don't think it makes sense for Sonarr. It feels a lot like FlexGet (or at least how I assume FlexGet to behave).

from sonarr.

Switching from SickBeard I feel that's the one key feature missing from Sonarr is the ability to prioritize your indexers. I have my premium (paid for) indexer and a few non-premium accounts setup in Sonarr. But with the current way Sonarr works it depletes my free accounts in one search.

If some prefer quality over anything else then let it work the way it does. Add a switch and give us the choice of using a ranking system on what to try first and stop searching each indexer if a file is successfully downloaded. The key need is it minimize those API calls. I for one don't care if I don't get the best quality file from my premium indexers, but I do like to have the option to try the free sites if it can't find it anywhere else.

from sonarr.

Same as above posters, i have my paid indexers and free indexers, and would love to first try out my paid indexers. example scenario: when my free indexer is over the API limit, my downloader receives an empty NZB and sonarr losses track of the episode from this point. Which means i have to go into sonarr, perform a manual search, and select my premium indexer.
Having some setting to go first to my main indexers would be great.

from sonarr.

+1 to this. This would be a major help to my automation.

from sonarr.

+1. I'd like to prefer trackers and have others as sort of a backup. It would only download from the lesser priority indexers if they had something the higher priority indexers didn't have.

from sonarr.

+1 for this as well. I'd love to search private before public.

from sonarr.

Implemented in v3 by #3899

from sonarr.