Optimal subtitle settings?

[K22R8CT 25]

Emby's subtitle matching doesn't work too well for me with Movies or TV. I'd say at least half the time I have to correct them using search to guess-and-check.

My libraries are mostly popular, english-language stuff.

I'm wondering if there are obvious tweaks I could make to providers, priority or anything else to improve it before I explore alternatives.

These are my settings for Movies:

and TV:

 

Edited January 22, 2022 by Anon28109

[GrimReaper 4749]

Enable hash matching, you'll get way less results - but they'll generally be synced. Note that it works with OpenSubtitles only. 

[K22R8CT 25]

1 hour ago, GrimReaper said:

Enable hash matching, you'll get way less results - but they'll generally be synced. Note that it works with OpenSubtitles only. 

Huh. So if the metrics are:

1. % of media matched correctly
2. % of media matched incorrectly

Enabling hash matching decreases (2) significantly. Does it also increase (1) ?

[GrimReaper 4749]

1 minute ago, Anon28109 said:

Huh. So if the metrics are:

1. % of media matched correctly
2. % of media matched incorrectly

Enabling hash matching decreases (2) significantly. Does it also increase (1) ?

It should effectively eliminate (2) and maximize (1). Note that you'll only get results if hash-match is found, else you'll get none - not close, not incorrect, it's match or nothing.    

[pwhodges 2013]

In particular, if you repackage or re-encode a video, then the hash match possibility is gone, and that's that.

Paul

[K22R8CT 25]

3 hours ago, GrimReaper said:

It should effectively eliminate (2) and maximize (1). Note that you'll only get results if hash-match is found, else you'll get none - not close, not incorrect, it's match or nothing.    

Got it. And I assume maximize implies increase (i.e. with Enable hash matching disabled (1) isn't already maximized.)

Without it are some providers more likely to give correct matches than others and if so, does their ordering on the library setup page affect which will be chosen?

33 minutes ago, pwhodges said:

In particular, if you repackage or re-encode a video, then the hash match possibility is gone, and that's that.

No repackaging or re-encoding in my setup but that makes sense.

[GrimReaper 4749]

2 hours ago, Anon28109 said:

And I assume maximize implies increase (i.e. with Enable hash matching disabled (1) isn't already maximized.)

Logic for subtitle downloads is Hash > Name > IMDB Id, with hash only being applicable to OpenSubtitles. If multiple matches are found, first one returned from provider is used. 

2 hours ago, Anon28109 said:

Without it are some providers more likely to give correct matches than others and if so, does their ordering on the library setup page affect which will be chosen?

It does, same as with meta-providers, order of preference is respected. In your case, SubDB>Addic7ed>OpenSubtitles>Podnapisi will hardly ever return a hash-match (when not required) as it is likely that name-match (or IMDB Id-match subsequently) will be found on first two providers. So, Emby "guessing" which subtitle to grab is very dependent on your media naming and availability. As for which provider is more likely to return correct matches, I'd say same applies. 

[K22R8CT 25]

10 hours ago, GrimReaper said:

Logic for subtitle downloads is Hash > Name > IMDB Id, with hash only being applicable to OpenSubtitles. If multiple matches are found, first one returned from provider is used. 

It does, same as with meta-providers, order of preference is respected. In your case, SubDB>Addic7ed>OpenSubtitles>Podnapisi will hardly ever return a hash-match (when not required) as it is likely that name-match (or IMDB Id-match subsequently) will be found on first two providers. So, Emby "guessing" which subtitle to grab is very dependent on your media naming and availability. As for which provider is more likely to return correct matches, I'd say same applies. 

Thanks, this is helpful. So the logic is:

• Search 1st provider for hash match else name match else IMDB match, else
• Search 2nd provider for hash match else name match else IMDB match, else
• ...

?

Wouldn't behavior be more intuitive if it were flipped, i.e.:

• Search all providers (in order) for hash match else
• Search all providers (in order) for name match else
• Search all providers (in order) for IMDB match

[Luke 42085]

11 hours ago, Anon28109 said:

Thanks, this is helpful. So the logic is:

• Search 1st provider for hash match else name match else IMDB match, else
• Search 2nd provider for hash match else name match else IMDB match, else
• ...

?

Wouldn't behavior be more intuitive if it were flipped, i.e.:

• Search all providers (in order) for hash match else
• Search all providers (in order) for name match else
• Search all providers (in order) for IMDB match

You can argue that I suppose, but then you're talking 3X the http requests to get the job done, which will cause the whole process to take longer as well as increase the chances of your account being rate limited or locked out temporarily.

[K22R8CT 25]

13 hours ago, Luke said:

You can argue that I suppose, but then you're talking 3X the http requests to get the job done, which will cause the whole process to take longer as well as increase the chances of your account being rate limited or locked out temporarily.

That's true but at the cost of worse matches (e.g. a higher ranked-provider matches on IMDB Id where a lower-ranked provider could have matched on name.)

Could set up a queue with rate-limiting to mitigate but I realize that's added complication.

I don't know if my setup's representative but it looks like most of the subtitle searching happens when media's added which isn't usually in bulk.

 

Turns out none of this would actually help me - apparently the issue's that I've switched to h265 and although the 264 subtitles are generally the right ones they wouldn't be a name match with any provider.

Anyway, thanks all for explaining it.