[mythtv-users] Fix for forced subtitle problems

[Paul Gardiner]

On 16/12/2023 15:46, Paul Harrison wrote:
> On 16/12/2023 14:18, David Hampton via mythtv-users wrote:
> 
>> On Sat, 2023-12-16 at 12:42 +0000, Paul Gardiner wrote:
>>> On 16/12/2023 02:12, Angela via mythtv-users wrote:
>>>> In my previous mails, I mentioned several times some misbehavior
>>>> which exists since many versions, which I think should be fixed
>>>> first, or what I suggested to not differentiate between forced and
>>>> non-forced, which makes the interaction much easier.
>>>> I am still hoping for comments.
>>>>
>>>> I have one request, please do not change the behavior of TOGGLECC.
>>> I don't think you need to worry about this going in against your
>>> wishes.
>>> I'm not a dev and can't just force this in. I wouldn't want to, in
>>> any
>>> case, without consensus. You are the only person who's taken any
>>> interest in this and you don't like it. I don't think it's going in.
>>>
>>> I wish you'd had the chance to actually try it before making up your
>>> mind - not with test videos - but in the wild, rather than imagining
>>> the
>>> scenarios, but that's my fault for not managing to get it to work on
>>> master. I've looked further and I can't see what the problem is. I'm
>>> parking it for now. I might return to it when 34 comes out and
>>> master,
>>> for a while, will be close to what I'm running.
>>>
>>> I didn't reply to many of your comments because I was hoping to wait
>>> for
>>> you to have tried it. Also I have no interest in trying to fix all
>>> the
>>> other misbehaviours. Plus, I find it very difficult to read very long
>>> detailed natural language pros, especially with all the references to
>>> forced and non-forced. I'm much happier dealing with one point at a
>>> time.
>>>
>>> I've just reread your previous posts. I believe I understand the
>>> points
>>> you are making. I'll have one last go to contrast what I think is
>>> your
>>> point of view with mine.
>>>
>>> I think I've found a better way to explain this with new terminology.
>>> I'll introduce a 3rd state: in addition to having On and Off, let's
>>> include Almost Off. I'll use Almost Off to refer to having a forced
>>> subtitle active. I think Almost Off is a good descriptive term
>>> because
>>> when a forced subtitle is active, mostly you see no subtitles. You
>>> could
>>> be fooled that subtitles are actually off, until just at a few
>>> specific
>>> points in the video, someone speaks Dothraki or Na'vi. I'm reserving
>>> the
>>> term On for showing a full subtitle. So in those terms:
>>>
>>> (I'm going to assume that the global setting "subtitles enabled" is
>>> false to keep things simple - for me - I like things simple).
>>>
>>>
>>>
>>> Option 1 - leave it as it is
>>>
>>>     If a video has no forced subtitle track then the player
>>> starts in the
>>> Off state. TOGGLECC toggles between Off and On.
>>>
>>>     If a video does have a forced subtitle track then the player
>>> starts in
>>> the Almost Off state. TOGGLECC changes internal state, but has no
>>> effect
>>> on whether or which subtitle is shown. To get to the On state, you
>>> have
>>> to use the menu to explicitly choose a non-forced subtitle. And once
>>> you've done that, you have to use the menu again if you want to
>>> return
>>> to the a forced subtitle.
>>>
>>> I think we both agree that that behaviour is not desirable.
>>>
>>>
>>>
>>> Option 2 - my interpretation of what you are suggesting
>>>
>>>     Whether a video has forced subtitles or not, the player
>>> starts in the
>>> Off state. TOGGLECC toggles between Off and On. If you want the the
>>> Almost On state, you have to use the menu to explicitly choose a
>>> forced
>>> track, and after doing so, you have to use the menu to get back to
>>> the
>>> On state.
>> I have not read the entire conversation, but I think this option is
>> wrong.  If a video has a forced subtitle track and it isn't displayed,
>> how will the user ever know that it is there and that they need to turn
>> it on?  The whole point of a forced subtitle is that when the
>> characters suddenly start speaking Japanese (or Klingon, or whatever)
>> that you are still able to follow the plot.
>>
>>> That's certainly an improvement over Option 1. It also has the
>>> advantage
>>> that we wouldn't even need the third state: On and Off alone are
>>> sufficient if we treat all tracks equally. The simplicity is nice. My
>>> objection is that it throws away a useful feature. I find it very
>>> useful
>>> to have a forced track appearing automatically, and to be able to go
>>> between that and a full track with a single button press.
>>>
>>>
>>> Option 3 - what my commits do (although seemingly not on master)
>>>
>>>     If a video has no forced track then the player starts in the
>>> Off state. TOGGLECC toggles between Off and On.
>>>
>>>     If a video does have a forced track then the player starts
>>> in the
>>> Almost Off state. TOGGLECC toggles between Almost Off and On. If you
>>> want no subtitles at all, not even forced then you have to use the
>>> menu to and select "Disable forced subtitles", whereupon TOGGLECC
>>> will then toggle between Off and On.
>>>
>>> In my opinion this is the optimal behaviour. It has more complexity
>>> in
>>> the programming, but is actually easier to use. You can still use
>>> TOGGLECC to obtain the full subtitles at any time, when you mishear
>>> something, but you get the non-forced automatically which you're
>>> likely
>>> to want because you don't understand Dothraki.
>> I agree that this is the optimal behavior.
>>
>> David
> 
> 
> Yep I agree with David this seems to be the way they should work. 
> Obviously if there are no subtitles or forced subtitles don't show the 
> option to turn them on in the menu's etc.

Thanks for weighing in on this. Good to get some more thoughts. I think 
at last I've found a reasonable way to describe the feature, after some 
rather confusing first attempts.

Also, it may now work on master. I eventually found a mistake in my 
conflict resolution. It's still untested on master, but the mistake I 
found certainly explained the failure, so I'm hopeful.