Preferred words with dots - Solved


#1

Sonarr version (exact version): 3.0.1.368
Mono version (if Sonarr is not running on Windows): 5.14.0.177
OS: lsio docker
Debug logs: N/A - I think
(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:

A preferred word such as “dd5.1” is not evaluated. “dd5” can be used as a workaround.
I guess due to the way dots are used as delimiter in release names, and the way sonarr parses them.


#2

possibly regex, maybe escape it and see if it works? dd5\.1

last comment i saw on matching was that it searched the entire string, including series title, so it shouldnt care about the . character


#3

Didn’t realize that regex also works in preferred words, awesome.
/dd5\.1/i and /ddp5\.1/i did the trick.

The /i is not required if you use /DD5\.1/ for example, but I kind of already know that if I use that, there’s gonna be a release with dd5.1 in lowercase :smile:

Thanks!


#4

/ddp?5\.1/i covers both cases in one shot, but as long as the release name has that period it should be handled properly, there would be an issue if it was dd5 1 though.


#5

I realize this is a bit of a hijack (apologies,) but could you post your final preferred words config? I believe your solution may be something I would use. The only player that can handle lossless audio besides a computer is the shield, so prioritizing files with lossy audio is what I have been trying to target. Or if this is published somewhere else, perhaps this could be added to a FAQ ?


#6

I went with markus’ suggestion and added /ddp?5\.1/i with a score of 100, and poked around a bith with https://regex101.com/ to create /[xh]265/i and gave that a score of 50.
I don’t know if it’s “cheaper” (processor-wise) to just create two entries x265 and h265 instead of the regex…


#7

At the scale it’s executing it probably doesn’t matter one way or another, my gut says the combined one would be more efficient, but on the other hand, maybe it’s not.


#8

/\b([xh].?265|hevc)\b/i would be better