Subdivx provider not working in 1.4.2-beta.6

[avraham]

Describe the bug
Subdivx provider doesn't find subtitles.
Subdivx recently revamped their website, but I installed v1.4.2-beta.6, on which it should be working, but it doesn't.

To Reproduce
Steps to reproduce the behavior:

1. Go to a movie and manually search for subtitles.
2. No subtitles are found and there are error messages in the logs. While there are subtitles in the website.

log file
bazarr (1).log

Expected behavior
Find the subtitle

Screenshots

Software (please complete the following information):

• Bazarr: Linuxserver.io version:- v1.4.2-beta.6-ls574 Build-date:- 2024-02-16T06:29:02+00:00
• Radarr version 5.2.6.8376

[morpheus65535]

Should be fixed in upcoming beta.7. Can you confirm please?

[avraham]

Sure. I'll test it in the next beta release.
Thank you.

[rmichelena]

@avraham , as you can see in the logs it's HTTP error 500 - it's an internal server error, it comes from Subdivx and it's transient. I've just tried and seems to work fine.
Try again and let us know.

[rmichelena]

I stand corrected. The matter is that there's an alternate title in Korean ; the request breaks Subdivx. If you try to search "플레이어스|" (that's the alternative title) in Subdivx's website UI, it hangs forever.
As it does not make sense to search non-latin character encodings in Subdivx, I'll try to add some code to detect and drop those alternate titles.

[morpheus65535]

@rmichelena my latest fix return [] on 500.

[rmichelena]

Ok, done ; tested with "Isle of Dogs (2018)" which has alternative titles in a lot of languages. Works ok.
I've forked and created a pull request, hope it's done correctly, first time contributing to a project :)

[rmichelena]

@morpheus65535 sorry didn't see your fix on time. Mine works differently, just avoids querying with titles that contain non-allowed characters (in allowed I include all European diacriticals too, and the German ß) - basically eliminating the Korean, Japanese, Russian, Chinese, Hindi, etc. that will break Subdivx.

I've merged your solution and mine ; because it might still happen that it'd return 500, but also it's better (and faster) to reduce queries (specially troublesome queries) to the provider. So my pull request is there.