Adopt media-streamer's live TV settings, and refill the restart budget on a picture

[ralyodio]

Streams played through the mpegts engine died after a minute or two on the same provider lines media-streamer plays all evening. Two causes; the second is what actually ended them.

1. The desktop profile fought the stream

configFor returned opposite settings per screen. The desktop half ran with no stash at all (stashInitialSize: 128 — bytes) and liveBufferLatencyChasing: true, on the reasoning that a laptop has bandwidth to spare and should sit close to the live edge.

Chasing is not polite about it — mpegts.js 1.8.2, live-latency-chaser.ts, whose own first line calls it "not recommended":

if (buffered_end - current_time > this._config.liveBufferLatencyMaxLatency) {
    let target_time = buffered_end - this._config.liveBufferLatencyMinRemain;
    this._on_direct_seek(target_time);
}

That is a hard currentTime seek, MSE rebuilds the decode pipeline on each one, and notifyBufferedRangeUpdate calls it on every appended fragment. It leaves only MinRemain — one second — of buffer behind. One second is a single jitter spike from an underrun; the underrun refills past the ceiling; it seeks again. Every cycle is a visible hitch, and every hitch is a chance to spend a restart.

Now one profile for every screen, taken from media-streamer's live TV player:

	was (desktop)	now
enableWorker	unset (false)	true
enableStashBuffer	false	true
stashInitialSize	128	384 * 1024
liveBufferLatencyChasing	true	false
lazyLoad	false	false (+ explicit durations)

A television was already getting most of this, which is why only desktops complained.

2. The restart budget almost never came back — this is the one that killed streams

It refilled only after thirty unbroken seconds, measured from the last restart and checked solely from inside the stall watcher. So three hiccups within half a minute spent the whole allowance and the stream was given up on permanently — even though every one of those restarts had worked and the picture was back within seconds.

On a provider line that drops a connection now and then (all of them), that is a hard ceiling of three recoveries per stream. Hitting it takes about a minute.

It now refills on playing, which is what media-streamer does and is the right event: it fires when the media element genuinely resumed, so the budget is spent by failures to recover rather than by failures. A channel that never plays still gives up after MAX_RESTARTS, because nothing ever fires it.

MAX_RESTARTS 3 → 5 and the backoff base 1.5s → 2s, to match.

Tests

91 pass, typecheck clean, prettier clean. Two new files:

• test/mpegts-config.test.ts — pins the profile as rules ("is the same on every screen", "never closes drift by seeking") rather than restating the object.
• test/mpegts-restart.test.ts — drives the engine against a mocked mpegts.js and proves the refill: four failures then a playing leaves the stream alive through five more, where the old rule ended it.

configFor and MAX_RESTARTS are exported for those tests; not part of the public API.

Note for hosts with a strict CSP

enableWorker: true makes mpegts.js build its worker from a blob URL, so a host serving a strict CSP wants worker-src blob:. Without it the library falls back and the only thing lost is the contention it was avoiding.

Minor bump to 0.4.0: same API, materially different playback behaviour.

🤖 Generated with Claude Code

https://claude.ai/code/session_01S5KxNHPQPY9Do9eWfJnGP4