Discrepancies with new Open Subtitles API Results When Using IINA #4749
Comments
|
Reproduced for me. Thanks for reporting this. I looked into the Open Subtitles REST API documentation again. The Search for subtitles section does not mention the API Guessit. I believe the intent is for the client to use this API to obtain additional information to pass when calling the search API. I will give this API a try and see if it can be used to fix this issue. |
|
I'm reporting here as well as stated in #4678. This is not very precise as the older version. As @low-batt said it is related to the new data expected by the Rest API. In my particular case I'm trying to download subs from TV episodes (Parks and Recreation for more context - "Parks and Recreation (2009) - S05E02 - Soda Tax (1080p AMZN WEBRip x265 Silence).mkv" ). |
|
@browser-bug Very helpful that you provided this second example. I thought it was the same problem shown by the example @tsegreto supplied. Turns out there is a second issue lurking. As seen here using the Guessit API works to narrow the search results:
I thought that would also correct the Parks and Recreation example, but it does not. If you search opensubtitles.org in the browser for this: Open Subtitles returns two results. But if you search opensubtitles.com Open Subtitles does not return any matches. It appears the .org site supports using the first year of the series and the .com site does not. If you rename the filename to use the year of the episode: Then the .com site returns 5 matches. I have reported this to Open Subtitles. My post is currently awaiting approval before it will be shown to the public. |
This commit will: - Add a guessit method to OpenSubClient class - Add a GuessitResponse struct to hold the results of a call to the Open Subtitles guessit API - Change the subtitles method to accept a GuessitResponse and pass information such as season and episode number as query parameters - Add a guessit method to OpenSub class - Change the searchForSubtitles method to accept a GuessitResponse and pass it on when calling OpenSubClient.subtitles - Change the OpenSub.Fetcher.fetch method to call guessit and pass the results to searchForSubtitles With these changes it is more likely that the results of searching for a particular episode of a TV series will be narrowed to subtitles for that episode.
This commit will: - Add a guessit method to OpenSubClient class - Add a GuessitResponse struct to hold the results of a call to the Open Subtitles guessit API - Change the subtitles method to accept a GuessitResponse and pass information such as season and episode number as query parameters - Add a guessit method to OpenSub class - Change the searchForSubtitles method to accept a GuessitResponse and pass it on when calling OpenSubClient.subtitles - Change the OpenSub.Fetcher.fetch method to call guessit and pass the results to searchForSubtitles With these changes it is more likely that the results of searching for a particular episode of a TV series will be narrowed to subtitles for that episode.
low-batt
added
progress: fixed/implemented
bug: regression
and removed
progress: pr ready
labels
|
The fix for this issue has been merged into the IINA The IINA 1.3.4 release was rushed out due to the end of year deadline to convert to the Open Subtitles REST API. Many tasks planned for 1.3.4 were left undone. We are continuing to work on the issues that missed the deadline and are planning a follow up release with those fixes along with the changes for this issue. On the "no results" problem… The topic I posted in the Open Subtitles forum regarding search not returning results for "Parks and Recreation (2009) - S05E02 - Soda Tax (1080p AMZN WEBRip x265 Silence).mkv" is: Search of .com returns no results, .org returns results No response as of yet. |
This reverts commit 7f31546. The commit being reverted added use of the Open Subtitles Guessit API in order to guess the season and episode of a TV series based on the filename. This worked and corrected the problem. However subsequently Open Subtitles reported the root cause of the failure to restrict search results to a particular episode was due to a temporary bug in their server's guessit system that has now been corrected. Thus there is no need for the client to use guessit.
…4774) This reverts commit 7f31546. The commit being reverted added use of the Open Subtitles Guessit API in order to guess the season and episode of a TV series based on the filename. This worked and corrected the problem. However subsequently Open Subtitles reported the root cause of the failure to restrict search results to a particular episode was due to a temporary bug in their server's guessit system that has now been corrected. Thus there is no need for the client to use guessit.
|
In this comment Open Subtitles indicated:
I've confirmed that IINA 1.3.4 is now returning subtitle search results that are for the specific episode. I have reverted the change I made on the client side to fix the problem. On the other problem, where a search for "Parks and Recreation (2009) - S05E02 - Soda Tax (1080p AMZN WEBRip x265 Silence).mkv" returns results if opensubtitles.org is used, but searching opensubtitles.com does not return any matches. Open Subtitles has indicated they are still porting problematic subtitles from the .org site to the .com site. As the Open Subtitles server issue has been fixed, I am going to close this issue. |
I've encountered a significant issue when utilizing the new API through IINA. The results returned by the new API deviate substantially from those provided by the old API. As an illustrative example, when I input 'The.Sopranos.S06E14.Stage.5.720p.WEB-DL.h.264.DD5.1-NTb.mkv', the API returns the likes of 'Sopranos 1x01', which is clearly inaccurate. This discrepancy raises questions about the source of the issue. It's unclear whether the problem lies within the IINA integration, the new API itself, or potentially changes in the Open Subtitles libraries. Further investigation or insights into this matter would be greatly appreciated.
System and IINA version:
The text was updated successfully, but these errors were encountered: