v1.12.1
Subtitles no longer burn themselves into the picture uninvited.
A PlaybackInfo request that names no subtitle stream does not mean "none" to Jellyfin — it means the file's default. For a file whose default track is a bitmap, the server built a transcode with that track re-encoded into the picture, so the episode came up with subtitles on for a viewer who had them off. Choosing Off sent another request naming no stream, and the server defaulted again: there was no way back.
Measured across the same five frames of the same episode — near-white pixels along the bottom of the decoded picture: 177 with subtitles off, 22,134 with the track deliberately chosen, 124 after choosing Off again. The middle number is burn-in working as it should. The other two were impossible before.
Also:
- A deep link to a PGS track (
?subtitle=N) went to the server to be burned in, rather than being drawn here as the menu already does — a transcode and a reload for a track that swaps instantly. - Every media-segment request was a 400, on every item. Jellyfin reads a comma-separated enum list as flags syntax, so two values parsed by accident and three did not. Repeated parameters are the form that binds. This one is latent — it matters once something is actually producing intro and credits ranges.
mov_text was checked at the same time and needed nothing: the server converts it to WebVTT cleanly, and it has been taking the ordinary subtitle path correctly all along.