This issue respects the following points:
Describe the bug
When a subtitle track is delivered via the Embed path during direct play, the player selects the wrong track: it renders the track at roughly half the requested server stream index.
On a file with many subtitle tracks this is trivially reproducible and fully deterministic. Selecting English SDH (server stream index 5) shows no subtitles at all, because index 5 maps to 2, and stream 2 is an audio track — so there is nothing to render and the failure is silent (no error, no crash).
ASS/SSA tracks are not affected, because the server burns those in (Restarting playback for subtitle baking) and that path uses the correct index. Only SUBRIP tracks, which take the method Embed path, are mis-mapped. This is what makes the bug confusing in practice: some subtitle tracks work perfectly while others silently do nothing.
Reproduction / evidence
Test file has 18 subtitle tracks at server stream indices 3–20. Each row below is a single selection from the in-player subtitle menu, with the corresponding log line and what actually appeared on screen (verified by screenshot and by grepping the server-extracted subtitle files for the exact rendered line):
| Menu entry selected (server index) |
Log line |
Actually rendered |
SDH - English - Hearing Impaired - SUBRIP (5) |
Enabling subtitle group 5 via method Embed |
nothing (→ index 2 = audio track) |
SDH - German - Hearing Impaired - SUBRIP (8) |
Enabling subtitle group 8 via method Embed |
English sub-script (→ index 4, ASS) |
European (SDH) - Spanish - Hearing Impaired - SUBRIP (12) |
Enabling subtitle group 12 via method Embed |
Arabic (→ index 6, ASS) |
Latin American (SDH) - Spanish - Hearing Impaired - SUBRIP (10) |
Enabling subtitle group 10 via method Embed |
English SDH (→ index 5) |
The relation rendered = floor(requested / 2) held for every case. The last row was predicted before testing and confirmed — selecting the Spanish LatAm SDH entry is currently the only way to actually display the English SDH track on this file.
The app resolves the menu entry to the correct server stream index (the Switching subtitles from index X to Y line is always correct); the mis-mapping happens when that index is handed to the player as a track "group".
Possibly related: #5407 (IndexOutOfBoundsException in StreamInfo.getSubtitleDeliveryMethod()) — that may be the same index mishandling in the case where the bad index falls out of range, rather than silently landing on a valid but wrong track.
Media info of the file
Matroska, direct played (play_method = DirectPlay), no transcode. Stream layout as reported by ffprobe:
0 video h264
1 audio aac jpn
2 audio aac eng
3 subtitle ass eng Forced (forced=1)
4 subtitle ass eng (default=1)
5 subtitle subrip eng SDH (hearing_impaired=1)
6 subtitle ass ara Saudi Arabia
7 subtitle ass ger
8 subtitle subrip ger SDH (hearing_impaired=1)
9 subtitle ass spa Latin American
10 subtitle subrip spa Latin American (SDH) (hearing_impaired=1)
11 subtitle ass spa European
12 subtitle subrip spa European (SDH) (hearing_impaired=1)
13 subtitle ass fre European
14 subtitle subrip fre European (SDH) (hearing_impaired=1)
15 subtitle ass ita
16 subtitle subrip ita SDH (hearing_impaired=1)
17 subtitle ass pol
18 subtitle ass por Brazilian
19 subtitle subrip por Brazilian (SDH) (hearing_impaired=1)
20 subtitle ass rus
21+ attachment (18 embedded fonts)
Client logs
I/PlaybackControllerHelperKt: Switching subtitles from index 5 to 8
I/PlaybackControllerHelperKt: Enabling subtitle group 8 via method Embed
I/PlaybackControllerHelperKt: Switching subtitles from index 8 to 12
I/PlaybackControllerHelperKt: Enabling subtitle group 12 via method Embed
I/PlaybackControllerHelperKt: Switching subtitles from index 12 to 10
I/PlaybackControllerHelperKt: Enabling subtitle group 10 via method Embed
For contrast, an ASS track selection takes the working path and displays correctly:
I/PlaybackControllerHelperKt: Switching subtitles from index 5 to 6
I/PlaybackControllerHelperKt: Restarting playback for subtitle baking
Application version
0.19.10 (also reproduced identically on 0.18.11)
Where did you install the app from?
Google Play Store
Device information
TCL Google TV (4K)
Android version
Android 14
Jellyfin server version
10.11.11
Other sources
No response
This issue respects the following points:
Describe the bug
When a subtitle track is delivered via the Embed path during direct play, the player selects the wrong track: it renders the track at roughly half the requested server stream index.
On a file with many subtitle tracks this is trivially reproducible and fully deterministic. Selecting
English SDH(server stream index 5) shows no subtitles at all, because index 5 maps to 2, and stream 2 is an audio track — so there is nothing to render and the failure is silent (no error, no crash).ASS/SSAtracks are not affected, because the server burns those in (Restarting playback for subtitle baking) and that path uses the correct index. OnlySUBRIPtracks, which take themethod Embedpath, are mis-mapped. This is what makes the bug confusing in practice: some subtitle tracks work perfectly while others silently do nothing.Reproduction / evidence
Test file has 18 subtitle tracks at server stream indices 3–20. Each row below is a single selection from the in-player subtitle menu, with the corresponding log line and what actually appeared on screen (verified by screenshot and by grepping the server-extracted subtitle files for the exact rendered line):
SDH - English - Hearing Impaired - SUBRIP(5)Enabling subtitle group 5 via method EmbedSDH - German - Hearing Impaired - SUBRIP(8)Enabling subtitle group 8 via method EmbedEuropean (SDH) - Spanish - Hearing Impaired - SUBRIP(12)Enabling subtitle group 12 via method EmbedLatin American (SDH) - Spanish - Hearing Impaired - SUBRIP(10)Enabling subtitle group 10 via method EmbedThe relation
rendered = floor(requested / 2)held for every case. The last row was predicted before testing and confirmed — selecting the Spanish LatAm SDH entry is currently the only way to actually display the English SDH track on this file.The app resolves the menu entry to the correct server stream index (the
Switching subtitles from index X to Yline is always correct); the mis-mapping happens when that index is handed to the player as a track "group".Possibly related: #5407 (
IndexOutOfBoundsExceptioninStreamInfo.getSubtitleDeliveryMethod()) — that may be the same index mishandling in the case where the bad index falls out of range, rather than silently landing on a valid but wrong track.Media info of the file
Matroska, direct played (
play_method = DirectPlay), no transcode. Stream layout as reported byffprobe:Client logs
For contrast, an
ASStrack selection takes the working path and displays correctly:Application version
0.19.10 (also reproduced identically on 0.18.11)
Where did you install the app from?
Google Play Store
Device information
TCL Google TV (4K)
Android version
Android 14
Jellyfin server version
10.11.11
Other sources
No response