Skip to content
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

Inconsistent hearing impaired/non-hearing impaired flagging #2386

Open
lawadr opened this issue Feb 11, 2024 · 3 comments
Open

Inconsistent hearing impaired/non-hearing impaired flagging #2386

lawadr opened this issue Feb 11, 2024 · 3 comments
Assignees

Comments

@lawadr
Copy link
Contributor

lawadr commented Feb 11, 2024

Describe the bug
When a subtitle is downloaded that is tagged as non-hearing impaired, but is scanned as hearing impaired, it is flagged as hearing impaired in Bazarr while saved without the "sdh" or "hi" in the file name. On rescan, it is re-flagged as non-hearing impaired in Bazarr.

To Reproduce

  • Find a subtitle that is flagged by the provider as non-hearing impaired but is detected as hearing impaired by Bazarr
  • Download the subtitle via a search or manual download
  • Notice that Bazarr detects it as <LANGUAGE> HI
  • Click "Scan Disk" and notice it getting changed to <LANGUAGE>

Expected behavior
Either it gets flagged as <LANGUAGE> and stays as <LANGUAGE> after a re-scan, or it gets saved with "sdh" or "hi" in the filename and continuously gets detected as <LANGUAGE> HI every re-scan.

Software (please complete the following information):

  • Bazarr: v1.4.1
@lawadr
Copy link
Contributor Author

lawadr commented Feb 11, 2024

It looks like the subtitle is saved to file based on what the provider thinks the language is. If it thinks it's English but not hearing impaired it'll get saved as *.en.srt for example

After that, guess_external_subtitles is called which reads the file and finds it to be hearing impaired. It is then saved to the database as being hearing impaired.

On re-scan, the language of an external subtitle is initially set based on its filename, which in this case is English non-hearing impaired as it's still just *.en.srt.

When guess_external_subtitles is called again, it does not read the file to change the language to hearing impaired because of the previously_indexed_subtitles_to_exclude argument. This makes it forever treated as non-hearing impaired.

My questions here are:

  1. Should the provider be trusted and the file always treated as non-hearing impaired? Or should the file scan during guess_external_subtitles be consistent from then on and it always being treated as hearing impaired?
  2. Should the result of guess_external_subtitles change the filename to match what it thinks it is?

@morpheus65535
Copy link
Owner

Yeah, I've been aware of that for a while but, probably out of laziness, I never fixed it.

I think that, while downloading a subtitles file, we should always validate if it's HI or not. The file should be named accordingly, not using the language known by the provider. guess_external_subtitles should then return the same value on each execution. Make sense?

@morpheus65535
Copy link
Owner

This should be fixed in upcoming beta. Keep me informed if it's as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants