From 44047284106dfc5c3cdd7cd0d43c13b96d191ca4 Mon Sep 17 00:00:00 2001 From: thePR0M3TH3AN <53631862+PR0M3TH3AN@users.noreply.github.com> Date: Tue, 28 Jul 2026 13:58:55 -0400 Subject: [PATCH] [playback] Add HLS support and stop blaming stale MediaErrors bitvid attached every hosted source with `videoEl.src = url`, which only plays HLS on Safari-family browsers. Firefox 146 fails with MEDIA_ERR_SRC_NOT_SUPPORTED (canPlayType returns ""), so every .m3u8 note -- e.g. anything published by nostube/slidestr -- was unplayable there and the URL-health badge showed "offline". Chrome/Brave 149 happen to play HLS natively, which is why this looked browser-specific. Vendor hls.js (npm run build:hls) and route HLS sources through it: - js/services/hlsPlayback.js owns detection, engine choice and the hls.js lifecycle. Engine choice keys off MediaSource, NOT canPlayType: Chrome returns "maybe" for every HLS type, so a native-first branch would hang. Native is used only when MSE is genuinely unavailable. - The bundle is the FULL build, not hls.js/light -- light drops the alternate audio stream controller and real ladders demux audio into an EXT-X-MEDIA group. It is lazy-imported only when a .m3u8 is encountered, so ordinary MP4/WebTorrent playback never pays the ~500KB. - modalCoordinator tears the instance down first; clearing `src` alone leaves the transmuxing worker and segment fetches running after the modal closes. - urlHealthController probes HLS by fetching the playlist for #EXTM3U. The old bare-