-
Notifications
You must be signed in to change notification settings - Fork 120
Movie Score 110, but subtitles are +7 sec. ahead of the action. #676
Comments
If you want to be sure that you will get perfect match, you absolutely need to have format matched too. This is not the case here. WEBRip is not same as BluRay. One version probably have one additional 7 seconds block in the beginning. I would not recommend setting score too high, since you might miss perfectly good subs, such as that one with score of 102 (witch actually match format). Based on your screenshot, those were matches: hearing_impaired 1 + year 30 + video_codec 2 + title 60 + resolution 2 + release_group 15 or 110 in total. In most cases, matching release group would more likely give you right subs than matching the format, since it is possible that someone mark format differently than someone else (for example webrip and webdl). Your filename "Spider-Man Far from Home (2019) Remux-1080p.mkv" doesn't have release group in it, so i am not sure why release group it is matched. Might be a bug in opensubs provider. Everything else is perfectly correct. Since @pannal is on vacation, I will try to check your logs and test this later myself if I find some time. |
Hi @viking1304 Thank you for your reply :-) I have looked everywhere for 'format match' but can not find this settings. Is it called something else in the SZ settings? I have Minimum score for moves set to 98 Regards |
Let's try to be as clear as possible to avoid any further confusion. A format is the source of your video (movie or series episode), that can be one of those: HDTV, BluRay, WEB-DL, WEBRip, DVDRip, ... A score that you are setting in SZ is called media score. Every element of your filename has a specific value in the final calculation. Your score set to 98 is perfectly fine. That is a minimal score. The minimal requirement to get a match if you use that value is that your file and subtitle have those same values: the same title, the same year, same format, and the hearing impaired flag the same title, the same year, same video codec, same audio codec, same resolution, and the hearing impaired flag In most cases, a higher score means that you will get subtitle that better match your video, but it is still possible that better subtitle has a lower score. It depends on your file name and what is set as release info for specific subtitle. Subzero will try to get as much info from your file name as possible, but you can still help a lot with better file names. I am not sure what was the problem in this specific case, but I will try to investigate if I find the time. |
Thank you for your explanation :-) So when you wrote "You absolutely need to have format matched too. This is not the case here" It is not an option that I have forgot to enable in the SZ settings? |
Sorry for confusion, I simply wanted to say that source of your file was BluRay and that you need BluRay sub if you want perfect match. You can't be sure that WEB-DL or WEBRip are perfect match for your video. I hope everything is finally clear. :) |
Thank you for your clarification :-) |
Edit: Clarification |
Wait, there's something fishy going on. Do you use advanced_settings.json and have skip_wrong_fps as False? SZ actually doesn't skip wrong FPS in OpenSubtitles for you. This might be a bug or a misconfiguration. |
Your SZ instance definitely goes into the else-block here: Sub-Zero.bundle/Contents/Libraries/Shared/subliminal_patch/providers/opensubtitles.py Line 72 in 72eeb7e
|
@pannal - if i am reading correctly, filename is Spider-Man Far from Home (2019) Remux-1080p.mkv and subtitle release is 1080p.WEBRip.x264-[YTS.LT] So how release group was matched? Looks like I bug, bud I didn't have time to look at logs or to test this. |
@viking1304 nah, all good. He uses Radarr as refiner; to reduce the load on the refiners SZ doesn't show the "real" filename in the menus. The filename that was searched for was It probably matched via tags on OS, matching the release group of a "similar release", which doesn't show in the menu, either (and we don't get that info from the API). The issue here is that SZ doesn't skip the bad FPS. It detects it properly, but takes the wrong path. |
I do not use the advanced_settings.json Is your conclusion that this is a bug or do you need more logs or testing from me? |
Can I have a log after an SZ restart? Ideally all your SZ logs zipped. |
I did a PMS docker restart - I hope that is the same as a SZ restart. I have attached all my SZ logs after the docker restart: |
You've actually hit a long standing bug. Neither default advanced settings where used when no advanced_settings.json was present. Disabling OpenSubtitles skip wrong FPS in the process (as well as another setting for OS). Please try latest develop. |
Thanks for bringing this to my attention. This will seriously improve the likeliness of false-positives for anyone not using advanced_settings.json on OpenSubtitles. |
You can actually test this fix by force-refreshing the item in question. |
(with old SZ dev version) At about 14:00 I upgraded to Sub-Zero 2.6.5.3144 DEV. I think there is a problem with 2.6.5.3144 DEV, because in Kitana I clicked on Spider-Man > Manage English Subtitle > List available English Subtitles > Search for English Subs Normally, after 30 sec. I can click on the 'refresh here' and I get a list of available subtitles, but now I do not get any subtitles. I did as you last requested - Restart the PMS docker, and ZIP all the Sub-Zero log-files. |
Damn. Holiday-mind is not up to snuff :D Edit: 3146 pushed |
I have installed 3146 and now I get a subtitles list. Spider-Man was upgraded, so I can not test if the match problem is fixed, but let hope so :-) |
Well you can - force-refresh it from the menu (Kitana). The issue was not the upgrade, but that SZ decided to use the subtitle with a bad framerate. |
I think there is another problem I would like to open a ticket for, but I am not sure if it is a SZ or Kitana issue. I therefore quickly ask you here - Hope that is ok :-) I have discovered that for some old TV Series, that have an external .srt subtitles file, Kitana says "No current subtitles in storage". For newer TV Series there is no problem. |
Yeah those are either external subtitles which were not provided by SZ, or the storage was corrupted for those older items. Nothing much that I can do there :/ |
When SZ talks about its "storage", it usually means the subtitle metadata storage that SZ manages itself, which holds score information, the actual content of the subtitle, source/provider etc. That is mainly used for subtitle modifications or upgrades. If it doesn't "know" about a subtitle (e.g. it doesn't have data stored for it from a previous download), it will say so. Edit: Not to be confused with the Plex Metadata storage, which can also hold subtitles (but no further information) |
Okay, fine - No problem, for the Subtitles are there and SZ can download a new one without any problems. |
It should also be able to download new ones for the ones without any subtitle in storage. It just wouldn't be able to find better ones than the existing ones, because it doesn't know how good the existing ones are. |
My pleasure :) |
This morning at 07:24, Radarr upgraded Spider-Man from Bluray to Remux, and SZ upgraded the subtitles.
When I played the movie, the subtitles was +7 sec. ahead of the action.
In Kitana I can see that SZ has scored the subtitles to 110. That is a quite high score for a movie, which normally gives a correct subtitle.
If you look at the attached Kitana screen dump, you can see that the subtitles with score 110 has “wrong FPS, sub: 60.000, media: 23.976”
If you look at the other attached Kitana screen dump, you can see that I did a manual install of the subtitles that scored 102. This subtitles played perfect without any offset problems.
The subtitles with score 102 has no error and match perfect with the movie.
My thought is therefore, if it is fair that SZ gives the subtitles with wrong FPS such a high score.
Could there be an error in the SZ code that scores wrong?
com.plexapp.agents.subzero.log
com.plexapp.agents.subzero.1.log
The text was updated successfully, but these errors were encountered: