dtourolle
2d67b0e4f5
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
56 lines
2.2 KiB
TypeScript
56 lines
2.2 KiB
TypeScript
/**
|
|
* What to do about a *fatal* hls.js network error.
|
|
*
|
|
* Jellyfin's transcoded HLS streams do not always terminate with an
|
|
* `#EXT-X-ENDLIST`, so a stream that has simply run out looks identical to one
|
|
* that broke: both arrive as a fatal network error. The only thing separating
|
|
* them is how far playback had got, which is why this decision is worth
|
|
* isolating from the player component — read the position wrong and a
|
|
* recoverable stall turns into a skip to the next item.
|
|
*
|
|
* TRACES: UR-004, UR-074 | DR-177 | UT-174
|
|
*/
|
|
|
|
/** Fraction of the runtime past which a fatal error reads as "the stream ended". */
|
|
const NEAR_END_FRACTION = 0.9;
|
|
|
|
/** How many times to ask hls.js to resume before giving up on the stream. */
|
|
export const MAX_FATAL_NETWORK_RECOVERIES = 3;
|
|
|
|
export type FatalNetworkErrorAction = "ended" | "retry" | "giveUp";
|
|
|
|
export interface FatalNetworkErrorInput {
|
|
/**
|
|
* Absolute position in the media, in seconds — the value the player displays.
|
|
*
|
|
* It is already absolute (`seekOffset + element.currentTime`): do NOT add the
|
|
* transcode seek offset again. After a quality switch or a transcoded seek the
|
|
* offset *is* the resume position, so double-counting it puts an apparent
|
|
* position past the near-end threshold from roughly halfway through, and every
|
|
* transient error then ends playback.
|
|
*/
|
|
positionSeconds: number;
|
|
/** Known runtime in seconds; 0 or negative when the runtime isn't known yet. */
|
|
knownDurationSeconds: number;
|
|
/** Recovery attempts already made against this hls.js instance. */
|
|
attempts: number;
|
|
}
|
|
|
|
/** Whether a failure at this position should be read as the stream ending. */
|
|
export function isNearEndOfStream(
|
|
positionSeconds: number,
|
|
knownDurationSeconds: number
|
|
): boolean {
|
|
if (knownDurationSeconds <= 0 || positionSeconds <= 0) return false;
|
|
return positionSeconds / knownDurationSeconds > NEAR_END_FRACTION;
|
|
}
|
|
|
|
export function fatalNetworkErrorAction({
|
|
positionSeconds,
|
|
knownDurationSeconds,
|
|
attempts,
|
|
}: FatalNetworkErrorInput): FatalNetworkErrorAction {
|
|
if (isNearEndOfStream(positionSeconds, knownDurationSeconds)) return "ended";
|
|
return attempts <= MAX_FATAL_NETWORK_RECOVERIES ? "retry" : "giveUp";
|
|
}
|