Selected subtitle track not showing up in player UI and changes audio track

[silentTeee]

Describe the bug

Thanks again for fixing the selection for burned-in subtitles, this issue seems to be isolated to the UI rather than impacting the playback itself:

1. Begin playing file with at least one subtitle track and multiple audio tracks, with no subtitle track selected
2. While playing the video, use the UI to change the audio track to the second one.
3. After video has started playing with the new audio track, use the UI to select a subtitle track
4. Observe the current subtitle track take effect, but the radio button is not selected, and the audio track changes back to the first option.

Logs

No response

Application version

2.5.0-beta.4

Where did you install the app from?

Sideloaded APK (proprietary build)

Device information

Google Pixel 7

Android version

Android 13

Jellyfin server version

10.8.9

Which video player implementations does this bug apply to?

• Web player (default)
• Integrated player (ExoPlayer)
• External player (VLC, mpv, MX Player)

[silentTeee]

Sadly, this issue still persists with server version 10.8.10, though it seems to be tied pretty exclusively to the client.

[Maxr1998]

What kind of media are you trying to play (container, tracks, codecs)? And are you direct playing or transcoding? Details like those are crucial for me to debug these issues.

[silentTeee]

Sorry for the late reply, I was out of town. I used the same source file that I used for #1017:

My Bride is a Mermaid - S01E11
Container: mkv
Size: 200 MB

Video
Title: 720p HEVC SDR
Codec: HEVC
Profile: Main 10
Level: 93
Resolution: 1280x720
Aspect ratio: 16:9
Interlaced: No
Framerate: 23.976025
Bitrate: 1153 kbps
Bit depth: 10 bit
Video range: SDR
Video range type: SDR
Pixel format: yuv420p10le
Ref frames: 1

Audio
Title: English - AAC - Stereo - Default
Language: eng
Codec: AAC
Profile: LC
Layout: stereo
Channels: 2 ch
Bitrate: 91 kbps
Sample rate: 48000 Hz
Default: Yes
Forced: No
External: No

Subtitle
Title: Signs/Songs (Doki) - English - Default - ASS
Language: eng
Codec: ASS
Default: Yes
Forced: No
External: No

Audio
Title: Japanese - AAC - Stereo
Language: jpn
Codec: AAC
Profile: LC
Layout: stereo
Channels: 2 ch
Bitrate: 98 kbps
Sample rate: 48000 Hz
Default: No
Forced: No
External: No

Subtitle
Title: Dialogue (Doki) - Japanese - ASS
Language: jpn
Codec: ASS
Default: No
Forced: No
External: No

Edited to add: also just like before, the file will "DirectPlay" until I introduce subtitles, after which it will switch to "Transcoding". I can reproduce the issue with a file that has similar tracks but uses PGS-based subtitles as well.

[silentTeee]

Would also like to add that beta.5 has this issue as well.

[silentTeee]

@Maxr1998 I remembered that part of how we debugged #1017 involved checking whether the issue went away if I toggled "Allow SSA/ASS subtitles in DirectPlay" in the client settings. After trying that, I was surprised to find out this issue also goes away!

[Maxr1998]

Right, it seems to occur when switching from direct play to transcoding, and having switched tracks first. I also know the cause and will try to fix it this week. Before we push another beta, could I send you a test build to confirm it's actually fixed then?

[silentTeee]

Yes, that's perfectly fine, happy to help! I will aim to test it tonight if it's available.

[Maxr1998]

Unfortunately I'm already busy tonight, but I'll ping you once I have something to test.

[silentTeee]

Sounds good! Sorry to bug you with this, in truth I actually tried to see if I could fix it myself, but calling my Android and Kotlin skills "shakey" would be kind...once I get good enough that I can reverse engineer Android projects, I will try to submit pull requests instead of bug reports. 🙂

[silentTeee]

Sadly 2.5.0-beta.6 also has the issue, though its unclear that the refactored play options selection was intended to completely fix this problem.

[Maxr1998]

It should've fixed this as well, actually. This seems to be a really odd edge case, so I can't promise we'll fix it before releasing 2.5 to stable. The bata cycle has already been way too long anyways. I'll look into this bug again if I have a bit more time.

[silentTeee]

Understood. Would it be helpful at all if I provided a sample of the file again, so you could test locally?

[Maxr1998]

Yes, that would be the best I think. Then I'll immediately know if it's fixed.

[silentTeee]

Sample sent via email. Best of luck!

[Maxr1998]

Thanks for the sample! I did some testing and can confirm that the UI doesn't show the currently selected subtitle or audio track while transcoding.

However, I couldn't reproduce the audio track change after selecting new subtitles (switched audio from English to Japanese or Japanese to English, then changed between all subtitle options a few times, audio always kept the current selection).
I have "Allow direct playback of ASS/SSA disabled" (that's why it transcodes when subtitles are selected). Can you check if it still happens for you, and if so, provide me the exact steps to reproduce?

[silentTeee]

Oh, good catch! You are right, the changes you made in 2.5.0-beta.6 actually did resolve the audio jumping back to the previous track! So now it's just the UI that seems to have issues.

And furthermore, I made a new observation while checking that reminded me of what you wrote in your description of #1038 regarding caching play state in the queue: I noticed that when I switch between transcoded subtitle tracks, the UI for the subtitle menu won't show any option selected, but then when I try to check the audio track menu, the audio track menu will now show the currently selected audio! Doing things in the opposite direction (changing between audio tracks when a subtitle track was previously selected, and then checking the subtitle track menu) also seems to reveal the current subtitles!

Could the UI state logic be caching old state just like the play queue was previously designed to do?

[silentTeee]

In fact, the UI caching old state might have been happening since the beginning, when I first reported #1017 ! See my comment from that issue submission

[Maxr1998]

Oh, good catch! You are right, the changes you made in 2.5.0-beta.6 actually did resolve the audio jumping back to the previous track! So now it's just the UI that seems to have issues.

Good to hear, thanks for the confirmation! It was indeed just a UI bug in the end.

The problem was that we invalidated the current selection for the changed track while transcoding, that explains why the changes applied for one type of tack (i.e., audio) if you changed the other track (i.e., subtitles). Hilariously, I fixed that exact same bug for the quality menu a few months ago. I have no idea why I didn't bother checking if they also apply to the audio and subtitle menus.