dtourolle/jellytau
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases 38 Wiki Activity

fix(player): give every transcode its own play session, and stop the one it replaces

Browse Source 
Switching bitrate mid-film stalled playback. The server served the new
playlist and then rejected its segments: 400 on hls1/main/0.ts, six times
over 25 seconds, never recovering, while the UI logged "Streaming quality
changed" as if nothing were wrong.

Jellyfin keys a transcode job by device and play session. Every stream URL
this app built carried the same hardcoded DeviceId and no PlaySessionId at
all, so the second stream for an item was indistinguishable from the first
and nothing ever stopped the old ffmpeg. Re-opening a stream is not rare —
a quality switch, a transcoded seek and an audio-track switch all do it.
Replayed against the server, a second stream opened for a live job's item
alternates per attempt between serving bytes and 400ing, which is why it
read as flaky rather than broken.

begin_video_play_session mints a session id per open and reports the one it
supersedes; the URL builder stops that job (DELETE /Videos/ActiveEncodings,
un-retried — a slow stop must not delay playback) before returning. Putting
it in the builder rather than in each caller covers every re-open path by
construction. adopt_video_play_session takes ownership of the job the server
starts itself when PlaybackInfo answers with a TranscodingUrl: without it the
first switch on a stream has nothing to stop and collides with what is
playing.

Two client faults made the same incident worse and go with it:

- The fatal-HLS-error handler added the transcode seek offset to a position
  that already included it. Past roughly the halfway mark of a film the
  doubled value cleared the "near end" threshold, so any transient network
  error was reported as end-of-stream and autoplay skipped to the next item
  — precisely when a quality switch had just made the offset large. The
  decision now lives in hlsRecovery.ts, against the absolute position.
- The HTML5 reload primitive resolved on its own canplay timeout, so a
  reload the server never served reported success. The picker showed a
  quality that was not playing and the caller had nothing to revert.

TRACES: UR-074, UR-004 | DR-177 | UT-173, UT-174, UT-175
This commit is contained in:
dtourolle
2026-08-16 09:47:27 +02:00
parent 13264e225b
commit 2d67b0e4f5
14 changed files with 4566 additions and 5424 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/lib/components/player/VideoPlayer.svelte
+24 -23
View File
@@ -14,8 +14,8 @@
import SleepTimerIndicator from "./SleepTimerIndicator.svelte";
import CachedImage from "../common/CachedImage.svelte";
import { videoFitClass } from "./videoFit";
import { fatalNetworkErrorAction } from "./hlsRecovery";
import {
subtitleStreamsOf,
resolveSubtitleTracks,
reconcileSelectedSubtitle,
videoCrossOriginMode,
@@ -333,18 +333,13 @@
}
}
// The subtitle streams the menu offers — the same list the <track> children
// and the native play request are built from, so the menu can never name a
// track the player was never given. subtitleStreamsOf() also drops the ones
// the backend says it cannot deliver as a sidecar (image-based PGS/DVD/DVB,
// which only server burn-in could show and we never ask for — DR-176).
// TRACES: UR-020 | DR-176 | UT-168
// Get available subtitle tracks from media streams
const subtitleTracks = $derived(() => {
if (!media || !media.mediaStreams) {
console.log("[VideoPlayer] No media or mediaStreams available for subtitles");
return [];
}
const tracks = subtitleStreamsOf(media.mediaStreams);
const tracks = media.mediaStreams.filter(stream => stream.kind === "subtitle");
console.log("[VideoPlayer] Found subtitle tracks:", tracks.length, tracks);
return tracks;
});
@@ -539,26 +534,32 @@
hls.on(Hls.Events.ERROR, (event, data) => {
console.error('[VideoPlayer] HLS error:', data);
if (data.fatal) {
// Check if we're near the end of the video - if so, this is likely
// end-of-stream rather than a real error. Jellyfin transcoded HLS
// streams may not always terminate cleanly with #EXT-X-ENDLIST.
// Is this the stream ending or the stream breaking? Jellyfin's
// transcoded HLS doesn't always emit #EXT-X-ENDLIST, so both arrive
// here identically and only the position tells them apart.
// `currentTime` is already absolute — see hlsRecovery.ts.
const knownDuration = media?.durationMs ? media.durationMs / 1000 : videoDuration;
const effectiveTime = currentTime + seekOffset;
const isNearEnd = knownDuration > 0 && effectiveTime > 0 && effectiveTime / knownDuration > 0.9;
switch (data.type) {
case Hls.ErrorTypes.NETWORK_ERROR:
hlsFatalRecoveryAttempts++;
if (isNearEnd) {
// Near end of stream - treat as natural end, don't restart
console.log('[VideoPlayer] Fatal network error near end of stream - treating as ended');
notifyEnded();
} else if (hlsFatalRecoveryAttempts <= 3) {
console.error('[VideoPlayer] Fatal network error, trying to recover (attempt', hlsFatalRecoveryAttempts, ')');
hls!.startLoad();
} else {
console.error('[VideoPlayer] Fatal network error, max recovery attempts reached');
hls!.destroy();
switch (fatalNetworkErrorAction({
positionSeconds: currentTime,
knownDurationSeconds: knownDuration,
attempts: hlsFatalRecoveryAttempts,
})) {
case 'ended':
console.log('[VideoPlayer] Fatal network error near end of stream - treating as ended');
notifyEnded();
break;
case 'retry':
console.error('[VideoPlayer] Fatal network error, trying to recover (attempt', hlsFatalRecoveryAttempts, ')');
hls!.startLoad();
break;
case 'giveUp':
console.error('[VideoPlayer] Fatal network error, max recovery attempts reached');
hls!.destroy();
break;
}
break;
case Hls.ErrorTypes.MEDIA_ERROR: