buildmymcpserver/apps
Marco Sadjadi 05746e13e6
All checks were successful
Deploy to Production / deploy (push) Successful in 59s
fix(video): drop WebM source + load()-before-play() + open-in-tab fallback
Owner: "wird nicht richtig gestream hab browser daten gelöscht aber kann
[nicht]" — clearing the cache didn't help. Three things changed:

1. **Single MP4 source.** Chrome listed the WebM source first because
   we offered it first; on the owner's setup the VP9 decode appears to
   stall silently and Chrome does NOT fall back to MP4 — it parks the
   element at networkState=2/readyState=0 forever. Removing the WebM
   source forces Chrome onto the MP4 (Main profile / yuv420p / TV-range
   / faststart, 2.6 MB) which we've already verified plays correctly.

2. **.load() before .play() in togglePlay.** When the original autoplay
   was blocked before the source ever fetched, some Chrome builds leave
   the element in a "stuck unloaded" state where subsequent .play()
   calls inside a user gesture also no-op. Calling .load() first resets
   the resource-selection algorithm, then .play() fetches and plays.

3. **playFailed escape hatch.** If .play() still rejects even after
   .load() + user gesture (extension sandbox, hardware decoder
   failure), surface a small "your browser blocked playback — open
   the video directly" link to the raw MP4. The visitor isn't trapped
   staring at a poster.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-28 03:26:56 +02:00
..
api feat(video): v10 hero video with mute toggle — voice + bg music 2026-05-28 02:31:10 +02:00
generator fix(tls): pivot per-runner TLS to path-routing on single subdomain 2026-05-25 22:51:30 +02:00
runner-template fix(docker): healthcheck must hit 127.0.0.1, not localhost 2026-05-21 18:07:01 +02:00
web fix(video): drop WebM source + load()-before-play() + open-in-tab fallback 2026-05-28 03:26:56 +02:00