Preferred Words mechanics

v3 Testing
#1

Sonarr version (exact version): 3.0.3.652
Mono version (if Sonarr is not running on Windows):
OS: Windows 10 (1903)
Debug logs:
(Make sure debug logging is enabled in settings and post the full log to hastebin/pastebin/dropbox/google drive or something similar, do not post them directly here. Post in .txt not .doc, .rtf or some other formatted document)
Description of issue:

I have been testing preferred words in v3 for the purpose of preferring HEVC/H265 releases with 10bit encoding and 5.1 audio.
Whilst the collection of preferred words I have selected has been largely successful, it still consistently fails when the uploader names the release incorrectly, because the preferred words engine seems to compare the file name of the original release rather than the carefully formed filename that I have configured via the renaming engine.

Here is an example:

I have the following preferred words set up
HEVC _ 0 points
x265 _ 0 points
H.265 _ 0 points
5.1 _ 0 points
6CH _ 0 points
10bit _ 0 poimts
2.0 _ -50 points
8 bit _ -10 points
x264 _ -100 points

(I use 0 points for my desired words, because I want to avoid doubling up on terms like HEVC & x265 which often both appear in release names and skews preferred word comparisons when given a positive score)

I monitor a series called Series.Name

Sonarr finds an early HEVC release called:
“Series.Name.S04E03.Episode.Name.1080p.AMZN.WEB-DL.DDP5.1.H.265 hevc SceneName.mkv”

The release name contains some of the preferred words I want (H.265, HEVC, 5.1) and is within the size limits for my quality profile, so it sends the release to my download client to be downloaded

So Far So Good

Once the file is downloaded, Sonarr renames the file and imports it into my library. My rename settings are:

{Series Title} - S{season:00}E{episode:00} - {Episode Title} - {MediaInfo VideoCodec}{MediaInfo VideoBitDepth}Bit - {MediaInfo AudioCodec}{MediaInfo AudioChannels} - {Quality Full}

So the renamed file is this:
Series.Name - S04E03 - Episode.Name - x265_10Bit - Opus_2.0 - WEBDL-1080p.mkv

You’ll notice that this is where the uploaders incorrectly named release is discovered. The file actually only has 2.0 audio, not 5.1 and also a different codec. We also discover at this point that the file is 10bit, which wasn’t in the original file name. (so an error and an omission in the original file name - at least in relation to the info that I am looking for)

Some time later, Sonarr finds another release. This time called:
“Series.Name.S04E03.Episode.Name.1080p.10bit.WEBRip.6CH.x265.HEVC-SceneName.mkv”

It checks this against the file in my library. I have Web-DL and Webrip as the same quality level and my quality cutoff is BluRay-1080p, to the first file “can be upgraded”
The new file passes all the std quality checks, so it compares the preferred words score

The new file has 3 of my preferred words (10bit, HEVC, 6CH), so it should have a higher score than the first file, which only has two of my preferred words (10bit, x265) and a non-preferred word (2.0) to which I have assigned a negative score

So the scores “should be”
current -50, new 0
and the new file should be downloaded and imported to upgrade the existing file

However, because the engine appears to be comparing against the original release name rather than my renamed file with the correct media info, we get the following entry in the debug log:
19-10-22 08:19:51.8|Debug|UpgradableSpecification|Comparing preferred word score. Current: 0 New: 0

and the new release is rejected (incorrectly, in my opinion) because “the existing file has an equal or better preferred word score”

In this particular example, this means that the only way to upgrade the existing file that is below my preferred level, is to find a release labelled BluRay-1080p, which will be months away at best

This system seems to be entirely dependent of the uploader naming their releases fully and correctly, but I don’t understand why we wouldn’t put some checks in to confirm this once the file is downloaded or even just give us the option to compare against the final file name (which will likely always contain the info the the individual user wants) rather than comparing against the original file name which most of the time will be inconsistent

#2

it is, always will be, and fakes do it deliberately. even if sonarr re-scored the file after it was downloaded and renamed (not a bad thing for it to do anyway), nothing will stop an incorrectly named torrent from potentially overriding it, or a badly named one from being “ignored”

#3

That is why I don’t use positive scores for my preferred words and negative scores for my non-preferred words. This way (assuming we re-scored after download), if I have an existing file that meets all my requirements, there is no way (other than a quality profile upgrade or possibly repack/proper processing) for a new file to outscore a known good existing file.

If the existing file in the library doesn’t meet all your requirements, (e.g. “Series.Name - S04E03 - Episode.Name - x265_10Bit - Opus_2.0 - WEBDL-1080p.mkv” from my original example) it will have a negative score, so new releases will occasionally outscore it based on the original release name

This could be because the original release name omits media details and therefore has none of your non-preferred words (e.g. “Series.Name.1080p.webrip.SceneName.mkv” which would score 0 with my preferred words), or is fully named, but has less non-preferred words than your library file (e.g. “Series.Name.S04E03.Episode.Name.1080p.WEB-DL.6CH.H265.hevc.8Bit.SceneName.mkv” which would score -10 with my preferred words and would score higher than the -50 in my example above).

This would trigger a download of a “potential” file. If the file is then re-scored after download and it still outscores the library file it is imported, if it doesn’t outscore the library file it can be discarded.

This may mean some extra download traffic, but i’d rather that than having to constantly manually check debug files to see if better files are being ignored due to scoring of your library file based on an incorrect original file name

#4

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.