How to increase ability of Sonarr to rank potential downloads

[goldcd]

Card:
I would like Sonarr to be aware of codecs and their implications on the quality of the video
So that size of download and stated resolution/source were no longer the sole criteria of my preferred download/library file

Discussion:
Sonarr currently triages downloads based upon the statements in the file-name and the size of the file.
Statements are currently restricted to stated resolution.

User Case:
The codec used is important. For a given file size, I’d prefer x265 over x264. Sonarr currently doesn’t offer me a way to prioritize x265.
Currently I have no mechanism to instruct Sonarr to download the “best quality video available” with the current criteria I can configure.

Thoughts:
Need a better mechanism to identify the preferred download. How to do this… well I’ve no idea.
Maybe support rule that file with x265/HEVC by default doubles (configurably) the triage score triage versus x264/AVC.
Stepping back (and massively increasing scope of Sonarr and opening a gigantic can of worms) - there’s an abstraction layer introduced. A Sonarr download analyzes a file downloaded, not based solely on name, but on content and “phones home” - and then feeds this info into future queries.

[markus101]

Sonarr currently triages downloads based upon the statements in the file-name and the size of the file.Statements are currently restricted to stated resolution.

That’s pretty close to the limit, beyond things such as age (usenet) or peers (torrents) there isn’t a lot of information available to pull in and with different feeds giving different information it’s tough to use indexer’s advanced fields (if they even enhance the data).

The codec used is important. For a given file size, I’d prefer x265 over x264. Sonarr currently doesn’t offer me a way to prioritize x265.

There is a GHI for that:

Issue: Preferred words (more release restriction awesomeness)

But it’s a bit of a can of worms and people are going to want different things, preferring what is available at a certain time is pretty easy, give a score the more preferred words something has and grab it, but if you want to make a decision what’s best now and also grab something that has a better score later it gets much trickier and you can’t reject something because it’s not a better quality upgrade without checking if it’s preferred word score exceeds the current file.

Also, what happens if the grabbed title has more information and gets a higher score than the imported file? If it’s upgrading based on that score it could grab the same release over and over (an issue we’ve seen with some WEB DL releases).

Currently I have no mechanism to instruct Sonarr to download the “best quality video available” with the current criteria I can configure.

Best quality in what way? Generally resolution and source are good indicators, save for some WEB-DL 1080p releases that are bit starved, but generally those can be filtered out via release restrictions.

Need a better mechanism to identify the preferred download. How to do this… well I’ve no idea.Maybe support rule that file with x265/HEVC by default doubles (configurably) the triage score triage versus x264/AVC.

That seems overkill, the scoring already in Sonarr is pseudo scoring really, things are still done in a specific order, otherwise you end up inflating numbers so high they are meaningless or could end up with a score that is broken in some way that it becomes the best one (preferred word matches boost it up or some sort of proper/real fight that gives it too many points (I’ve seen releases with REAL and PROPER in it multiple times).

Stepping back (and massively increasing scope of Sonarr and opening a gigantic can of worms) - there’s an abstraction layer introduced. A Sonarr download analyzes a file downloaded, not based solely on name, but on content and “phones home” - and then feeds this info into future queries.

We talked about something like this once upon a time, but currently it’s not something we’re considering the scope part of it plays a big part.

[goldcd]

Thanks for the detailed reply.
My original post was most definitely my random ramblings, and this is me now trying to consider how a useful improvement could be implemented.
As it stands within Sonarr I can select the resolution I wish for (e.g. 720 or 1080) based upon the header, and I then modify for the file size within this I wish to download.
e.g. 2Gig limit on a 1080p download.

Two, I hope, easy features that would be useful are:

1. If I set a limit of 1-3GB for a 1080p download, for Sonarr to look to replace an existing file I have if something closer to the upper limit comes along.
   E.g. I have a 1.1GB 1080p file, then a 2.9 GB file appears, simply to have a checkbox on my preferences to indicate I’d like to download/replace.

2. Have a very simple keyword rating. MPEG2 is 0.5, x264 is 1, x265 or HEVC is 2
   When a scan is run for what’s out there, the multiplier is applied to give a pseudo size, versus the ‘real size’.
   The limits from point 1 are then run against this new ‘pseudo-size’

[markus101]

f I set a limit of 1-3GB for a 1080p download, for Sonarr to look to replace an existing file I have if something closer to the upper limit comes along. E.g. I have a 1.1GB 1080p file, then a 2.9 GB file appears, simply to have a checkbox on my preferences to indicate I’d like to download/replace.

What if you wanted smaller files? You end up with multiple options (or values for the options) and end up having to rewrite the entire decision process to avoid it being immediately rejected because it’s not a quality upgrade. It also complicates things if you’re not getting proper sizes from the indexer; either they’re completely wrong or include par2 files (usenet) and it could throw Sonarr into a loop of grabbing, importing and repeating without fail safes in place.

Have a very simple keyword rating. MPEG2 is 0.5, x264 is 1, x265 or HEVC is 2When a scan is run for what’s out there, the multiplier is applied to give a pseudo size, versus the ‘real size’.The limits from point 1 are then run against this new ‘pseudo-size’

That seems like a complex version of preferred words, which in itself is a can of worms whether a new release will upgrade existing files because it contains more preferred words than that existing file. It also seems like a support trap, where there will be few people that understand how it works and everyone else that tries will end up looking for help (to some degree re-ordering qualities in a profile has this issue).