New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Opensubtitles doesn't find any episodes subtitles released after 17 Oct #1168
Comments
It's an issue with imdb number with a leading |
@morpheus65535 I cloned it in the portainer using linuxserver/bazarr:development instead of :latest, it's now v0.9.0.6. But the manual search for those 2 shows still doesn't have opensubtitles in it, so it's possibly a different issue (or I'm using the wrong dev version?). Also it worked for some other shows both in dev and stable. But not for the ones in the logs. For the affected shows there's nothing in the logs related to the opensubtitles after those lines:
For unaffected shows it looks normal like this:
and a lot of lines like the last one after |
It means that OpenSubtitles returned subtitles but they get excluded because they don't really match for one of those reasons: https://github.com/morpheus65535/bazarr/blob/master/libs/subliminal_patch/providers/opensubtitles.py#L305-L322 |
But my settings for both shows are: English, Russian, Hearing-Impaired: False Forced: False Opensubtitles indeed doesn't say anywhere in my logs that "No subtitles found", that means that response is definitely not empty and is filtered out in the process? Then I can't really explain why those lines come up with nothing, and not sure how I could live-debug this:
Also, should the languages duplicate like that? I feel like some of my settings could be corrupted after the update, but I set a lot of things manually, so would like to avoid a reset if possible. |
I've run debugger with |
@morpheus65535 maybe we can open a ticket at OS for investigation? --> https://trac.opensubtitles.org/projects/opensubtitles/report |
I've sent a msg to the admin on Slack. Waiting for feedback. |
Thank you for investigating! I hope they will fix it eventually, cause it is basically the only provider that has Russian subtitles, for the recent titles at least. |
@opensubtitles told me that they're going to rerun the indexer to make sure this doesn't happen. |
I reindexed the db, but the problem persists. It is very strange and I really dont understand. If you can send more examples when this happen, maybe I will know more. (try with season and episode, without it etc etc). |
@opensubtitles I could try to play around with the queries, but I never worked with XMLRPC before, and can't figure out if there's an easy way to access the api, like some public web sandbox, or a postman import? I found npm api wrapper though, will try setting it up later. |
I've tested a few of my shows in bazarr and I've experienced new examples of the error. In all of them, previous episodes (if there are any) work, but the one from example and the next ones do not. I think the common denominator is the sub upload date: everything up until (and including) 15 Oct works, everything after 17 Oct does not. Did anything change on your end around that time maybe? Older shows seem not affected. Only my ongoing shows (every one of them) have that issue for every episode starting from this one: Warrior, S02E03, upload date 17 Oct The Spanish Princess, S02E02, upload date 18 Oct Pandora (2019), S02E03, upload date 19 Oct Star Trek: Discovery, S03E02, upload date 22 Oct Barbarians (2020), S01E02, upload date 23 Oct The Undoing, S01E01, upload date 26 Oct This is Us, S05E01, upload date 28 Oct I also did some test requests based on those lines from my initial logs that reproduced the error:
I've used npm api wrapper in the end, cause it was easier for me to make its response readable. It says it prioritizes by: Hash + filesize => Filename => IMDBid (+ Season and Episode for TV Series). I can't try it without season+episode completely, cause the temp agent limits to 5 (I've sent a user agent request today). My findings (works for both examples): I have 720p versions, so it's reasonable if my hash and size don't find anything, but if I also try existing bytesize from the webpage, it also doesn't work in a search query for any episode actually, so I'm not sure if I'm doing it right. I'm taking it from here: I'm not sure how npm api prioritize things (cut off or a chain of requests), but it looks like the 'query' parameter does not work for those new episodes? Can I do any other tests to help? |
@opensubtitles any chance of getting this fixed? |
@morpheus65535 probably they're still looking into it https://forum.opensubtitles.org/viewtopic.php?p=44590#p44590 By the way, I tried to find out if there is some specific reasoning behind bazarr using Since the api issue is only with
I suppose it's because |
I've just pushed some changes to OpenSubtitles provider in dev branch. Seems to be working for me. Can you test it? |
I had to wait for linuxserver development image to update first, but after I pulled it, it's working now as intended, with imdbid in the request. Thanks for the fix! |
please check again, I think I have fixed it. It was caused by IDs (integer) overflowing. |
Describe the bug
I turned on the debug mode for this. Logs: https://hastebin.com/weyegawenu.sql
In the logs look for the Star **** and The Spanish ******** show searches. It looks like opensubtitles does connect, but gives only movies results for the first show, and nothing for the second? That's strange cause bazarr downloaded previous episode subs of those shows from opensubtitles with no problem (before I updated the docker image), but now there's no opensubtitles subs in any language in the manual search. And this provider is usually the only option for my language. Please look into it. I hope the info I provided is enough.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
It should show up in the manual search if the subs exist on the site and the same show was matched fine by bazarr to opensubtitles before.
Software (please complete the following information):
The text was updated successfully, but these errors were encountered: