v1.5.8 — audio-restore hotfix (disable MSE, cache-bust receiver)

PC Nest Speaker 1.5.8 — audio-restore hotfix

Receiver-only change. MSE attempt is disabled. The dispatcher routes straight to the plain <audio src=> path that has worked since 1.5.0.

Why

Real-device testing of 1.5.6 and 1.5.7 on Nest Mini showed the receiver hanging forever at mse-fetch-start with no fallback ever firing — even after the 1.5.7 watchdogs were added. Most likely cause is the Cast Audio Chromium runtime caching the old (no-watchdog) receiver HTML despite force_relaunch, or the runtime not honoring setTimeout/AbortController.abort() during a hung fetch(). Either way, the user got no audio.

1.5.8 is purely about restoring playback. No latency improvement claims. Latency on 1.5.8 ≈ 1.5.5.

What's still in the code

connectHttpPcmMse() stays in receiver-audio.html for now. The dispatcher no longer calls it — it's unreachable. Will revisit once the research agent reports back on:

1. Whether XMLHttpRequest + responseType="arraybuffer" + onprogress works for incremental chunk delivery on Cast Audio (where fetch().body.getReader() doesn't), or
2. Whether to pivot to the owntone-server pattern — Google's built-in mirroring receiver 85CDB22F + Cast RTP / Opus / targetDelay=400. That's the only open-source path proven to hit ~400 ms total latency on Cast Audio, but it's a 1–2 week transport rewrite.

If audio is still dead after upgrading

The Cast Audio runtime caches receiver HTML (HTTP Cache-Control: max-age=600 from GitHub Pages). To force a fresh fetch:

1. Open the Google Home app, find the Nest Mini, hold the icon → "Restart". Or unplug it for 10 seconds.
2. Cast again from PC Nest Speaker.
3. The fresh receiver load will pick up the 1.5.8 receiver code.

Files changed

• pcnestspeaker-receiver/receiver-audio.html — dispatcher routes straight to <audio> path
• package.json — version bump