v1.14.11

fix: stop infinite self-heal restart loop and stale-timeout recording…

v1.14.10

fix: self-heal drives a real stop+reopen instead of an in-place HLS r…

v1.14.9

fix: self-heal now tears down the DVR session before reconnecting

v1.14.8's watchdog correctly detected the frozen cold-start pattern and
triggered recovery, but recreating the HLS.js instance against the same
manifest URL just reattached to the same stuck CC4C session server-side,
getting caught in the same buffer-hole/stall loop. Console diagnostics
showed clean playback only started after a real manual stop, which calls
stopLiveDvrSession() first. Self-heal now does the same before reconnecting,
with a short pause mirroring the natural gap a manual stop/reopen has.

v1.14.8

fix: self-heal watchdog missed the genuinely-paused failure mode

The frozen-frame check required !vid.paused, assuming playback would be
stuck while playing. The actual failure is the element sitting genuinely
paused (play() still not reliably unblocked), so that guard was never true
and the watchdog silently did nothing. Removed the paused requirement and
added console diagnostics on every tick so the next test gives concrete
evidence if this still doesn't fully resolve it.

v1.14.7

fix: auto-recover from live channel cold-start playback artifacts

Fresh channel tunes can produce a frozen frame or heavy dropped-frame
choppiness for the first few seconds, likely from Channels DVR's live
encoder pipeline still ramping up. Diagnostics showed this is front-loaded
(all drops happen early, zero afterward), and manually stopping/restarting
the channel always fixes it. Added a one-shot watchdog that detects the
frozen/choppy pattern in the first several seconds of a live tune and
automatically tears down and recreates the HLS.js instance against the same
manifest URL, mirroring the manual workaround without requiring it.

v1.14.6

fix: make live channel autoplay reliable and repaint after resume

Live channels resolve their manifest URL through several sequential HEAD
probes, which can outlast the user gesture that opened the channel by the
time play() fires from the async MANIFEST_PARSED callback. WebKitGTK then
silently leaves the video paused with a full buffer instead of rejecting
cleanly, matching the frozen currentTime/climbing readyState seen in the
reporter's console log. Start muted (unconditionally allowed) and restore
the prior mute state once play() resolves, and nudge currentTime for live
streams to force a repaint after resuming, mirroring the incidental fix
recordings already get from their resume-position seek.

v1.14.5

fix: recover from non-fatal buffer-hole/stall errors on live channel …

v1.14.4

fix: correct webkit2gtk package name and bundle GStreamer HLS plugins…

v1.14.3

v1.14.3: fix remux-fallback AbortError surfacing as a playback error

v1.14.2

v1.14.2: fix v1.14.1 release build and bundle GStreamer in the AppImage