[mythtv-users] Fix for forced subtitle problems

Angela angela.schmid at wolke7.net
Fri Dec 15 14:43:51 UTC 2023

>Anyway, here is what I see with all 3 commits applied to fixes-33:
>I start the movie and make no adjustment to any subtitle settings. I see subtitles displayed "Using subtitle_eng_forced.srt" and then "This is an English Forced Subtitle example."
>I then use Right Arrow repeatedly to navigate back to the start of the movie and press the T key once. I see subtitles displayed "Using subtitle_eng.srt" and then "This is an English Subtitle example."
>This is the behaviour the commits were designed to achieve. What do you see if you perform the same key presses?

Tried with master and the 3 commits, the non-forced is not showing, it behaves different depending on the global setting of subtitles enabled/disabled:

With global setting "subtitles disabled"
At start: "Using subtitle_ger_forced.srt" (as I have german configured)
Back to start of movie
Press TOGLLECC: OSD "German forced OFF"
Shows "Using subtitle_ger_forced.srt"

With global setting "subtitles enabled"
At start: "Using subtitle_ger_forced.srt"
Back to start of movie
Press TOGLLECC: OSD "German non-forced ON"
Shows "Using subtitle_ger_forced.srt" (the non-forced is not shown)

Somehow it doesn't work on master.

My current observations:

TV Playback	NEXTSUBTITLE	Next subtitle track
TV Playback	TOGGLECC	Toggle any captions => on/off view => behavior should not change.

TOGGLECC should not change its behavior,  it is used to toggle the display of the subtitles on or off.

With master
Selecting different subtitles is working on master and can be looped through with NEXTSUBTITLE. TOGGLECC is working.

The only thing what is very confusing is the behavior of the menu having an enable/disable for forced and non-forced, simultaneous with TOGGLECC. The accompanying OSD messages are not consistent.
The easiest would be to not differentiate between forced and non-forced and just have one option and enable/disable the subtitle currently shown.

In detail with suggestions (please comment):

>Forced subtitles are often used when characters start speaking a language other than the "main" one in the movie. E.g., if it's an English-language movie and two characters start having a conversation in Japanese, forced subtitles will show the English translations of what the Japanese-speaking characters are saying.
>I think it's common in the US, but I'd be surprised if it's only in the US. I mean, unless everyone outside the US is also fluent in Klingon or Dothraki, people everywhere will need those subtitles. :)

Correct, and also the forced subtitles are included in the non-forced subtitles.

The “forced” flag tells the Matroska Player that it SHOULD display this subtitle track, even if user preferences usually would not call for any subtitles to be displayed alongside the current selected audio track. This can be used to indicate that a track contains translations of onscreen text, or of dialogue spoken in a different language than the track’s primary one.

This is also how it is implemented on master:
With global setting "subtitles disabled: it shows the forced subtitle (for Television: no TT subtitle, correct)
With global setting "subtitles enabled: it shows the forced subtitle (for Television: shows TT subtitle, correct)

Currently the following problems/confusion exist:
TOGGLECC on the forced subtitle, does not have an impact, although it says "off", it will always be displayed. Only "Disable Forced Subtitles" from the menu disables them. 
After a non-forced subtitle is selected (menu or NEXTSUBTITLE), and thereafter a forced subtitle is selected TOGGLECC also works. I think the forced is then handled similar as if it is a non-forced subtitle.
Selecting "Enable Forced Subtitles" does not bring them back.
When using TOGGLECC, the menu state of "Enable/Disable Forced Subtitles" and "Enable/Disable Subtitles" is not always correct, maybe it has something to do, that at one point a forced is handled as a non-forced subtitle as mentioned before.
The most consistent behavior is, when no menu options are used.

The menu options do not work as expected, we might fix it half way, but it will still be very misleading what is the expected behavior. 
Therefor I suggest to have just ONE menu option (enable/disable subtitle), independent of what is currently shown (forced/non-forced, even TT subtitles and external). TOGGLECC already works like this.
I haven't seen any other media player, having an option to enable/disable a forced subtitle, they can select "disable" or a subtitle (forced or non-forced) out of a list.
<please comment>

As currently implemented forced subtitles are displayed with either global setting "subtitles disabled" and "subtitles enabled".
I would suggest (prefer) when global setting "subtitles enabled" the non-forced are displayed (the non-forced contain the forced subtitles so we are not missing something).
<please comment>

Otherwise, when some people would prefer when "subtitles disabled" the non-forced should not be displayed, I would suggest to add a third option, to differentiate between which subtitle to enable, forced or non-forced.
This would need more coding.
<please comment>

Next to forced and non-forced "language" subtitles, other types of subtitles can exist (director comments, closed captions (sirens, footsteps), subtitles with additional information for heavy hearing impairment (who is speaking, narrated actions)), these are easiest selected with NEXTSUBTITLE. Looping through them goes quick.
About Paul's implementation "flipping between forced and non-forced", unfortunately it didn't work for me on master to see further impacts, when for example selecting another language subtitle, what is the intended behavior, will it flip between them in the newly selected language. 
I appreciate everybody's work, but I doubt it is a big winner, I haven't seen something similar in another media player. It would need another key (and menu). IMO it would lead to further confusion.
<please comment>

The ambiguous "usage" of forced and non-forced resulted that during time it got broken. 
Paul's intention was to fix and add some new behavior, which IMO complicates it more. Currently the 3 commits work on v33, but not on master, which would need to be investigated. I mentioned the "state" problems (although the issue exists in several previous versions).
The above is about ripping stuff out, making it easier, which leads immediately to behavior as expected.

I hope many of you comment on the above suggestions and/or present another view on the topic.

More information about the mythtv-users mailing list