timothy/ersatztv
1
0
Fork 0
Code Issues 57 Pull Requests 6 Actions Packages Projects Releases 9 Wiki Activity

Channel preview can sit at "starting" when autoplay is blocked, with no hint to press play #554

New Issue
Closed
opened 2026-07-21 23:22:21 +02:00 by timothy · 4 comments
timothy commented 2026-07-21 23:22:21 +02:00
Owner
Copy Link
Copy Source

Split out of #60 (PR #551) — a known limitation shipped knowingly, not a regression.

Problem

HlsPlayer sets manifestLoadPolicy.maxTimeToFirstByteMs: Infinity because ErsatzTV's manifest GET blocks until segments exist (inherited from the troubleshooting use case, where that blocking is intended and correct).

Consequence for the preview panel: on a slow-starting channel, MANIFEST_PARSED can arrive well past the browser's transient user-activation window (~5s in Chrome). video.play() is then rejected as blocked autoplay, no playing event fires, and the panel sits at state starting over a black frame — with no indication that the operator simply needs to press play.

This is honest (it does not claim to be playing — that lie was fixed in #60), and the native <video controls> play button is right there. But for a tool whose job is answering "does this channel work?", "starting forever" is an unhelpful answer that looks identical to a genuine stall.

Options

  • Add muted + autoPlay to the <video> element so autoplay is permitted (muted autoplay is allowed without user activation). Preview is a diagnostic, so muted-by-default is arguably correct anyway — though it makes audio-presence unverifiable until unmuted.
  • Detect the rejected play() promise and surface an explicit "autoplay blocked — press play" hint.
  • A time-boxed hint: after N seconds still in starting, show what to check.

The first two are complementary; the muted-autoplay route is the smaller change and removes the failure mode rather than annotating it.

Done-when

  • A preview that cannot autoplay either starts anyway or tells the operator what to do
  • Covered by a web test
  • docs/spa-conventions.md §5b updated if HlsPlayer's element attributes change
  • Adversarial review passed
Split out of #60 (PR #551) — a known limitation shipped knowingly, not a regression. ## Problem `HlsPlayer` sets `manifestLoadPolicy.maxTimeToFirstByteMs: Infinity` because ErsatzTV's manifest GET **blocks until segments exist** (inherited from the troubleshooting use case, where that blocking is intended and correct). Consequence for the preview panel: on a slow-starting channel, `MANIFEST_PARSED` can arrive well past the browser's transient user-activation window (~5s in Chrome). `video.play()` is then rejected as blocked autoplay, no `playing` event fires, and the panel sits at state `starting` over a black frame — with **no indication that the operator simply needs to press play**. This is honest (it does not claim to be playing — that lie was fixed in #60), and the native `<video controls>` play button is right there. But for a tool whose job is answering *"does this channel work?"*, "starting forever" is an unhelpful answer that looks identical to a genuine stall. ## Options - Add `muted` + `autoPlay` to the `<video>` element so autoplay is permitted (muted autoplay is allowed without user activation). Preview is a diagnostic, so muted-by-default is arguably correct anyway — though it makes audio-presence unverifiable until unmuted. - Detect the rejected `play()` promise and surface an explicit *"autoplay blocked — press play"* hint. - A time-boxed hint: after N seconds still in `starting`, show what to check. The first two are complementary; the muted-autoplay route is the smaller change and removes the failure mode rather than annotating it. ## Done-when - [x] A preview that cannot autoplay either starts anyway or tells the operator what to do - [x] Covered by a web test - [x] `docs/spa-conventions.md` §5b updated if `HlsPlayer`'s element attributes change - [x] Adversarial review passed
timothy added the priority: lowfrontend labels 2026-07-21 23:22:21 +02:00
timothy added the in-progress label 2026-09-05 01:04:08 +02:00
timothy commented 2026-09-05 01:04:08 +02:00
Author
Owner
Copy Link
Copy Source

Claiming #554. Working on branch 554-preview-autoplay-blocked-hint, worktree /Users/timothy/orca/workspaces/ersatztv/wt-554.

Claiming #554. Working on branch `554-preview-autoplay-blocked-hint`, worktree `/Users/timothy/orca/workspaces/ersatztv/wt-554`.
timothy commented 2026-09-05 01:39:03 +02:00
Author
Owner
Copy Link
Copy Source

SUPERSEDED — do not read this as the outcome. Replaced by the closing record at #554 (comment 26478). This record describes only the branch's first commit; the muted-unconditionally behaviour, the onPlaying clear and the "findings folded into the diff" claim below were all reversed or were false. The measurements below are of that first commit.

Closing record

Outcome: PR #910 (#910) — HlsPlayer now renders <video> muted unconditionally so autoplay is never blocked in the common case, plus an optional onAutoplayBlocked() callback for the residual case (stricter browser policy/extension); ChannelPreviewPanel wires it to a "press play" hint shown only while state is still starting.
Root cause: manifestLoadPolicy.maxTimeToFirstByteMs: Infinity (needed because ErsatzTV's manifest GET blocks until segments exist, #60/PR#551) means MANIFEST_PARSED can arrive past the browser's ~5s transient user-activation window on a slow-starting channel, so video.play() is rejected as blocked autoplay with no playing event and no hint to the operator.
Decisions/conventions changed: none new — extends the existing HlsPlayer optional-callback convention (onError/onPlaying) documented in docs/spa-conventions.md §5b.
Reusable knowledge: muted autoplay removes the failure mode outright rather than annotating it (per the issue's own analysis) — the residual onAutoplayBlocked path exists only for policies stricter than "blocks autoplay of unmuted media", which is the common browser default this fix targets.
Verification: npm run check:api && npm run lint && npm run typecheck && npm run build clean; npm test 121 files / 1332 tests passed (2026-09-05), including 4 new HlsPlayer tests and 3 new ChannelPreviewPanel tests pinning the muted attribute, the callback firing/not-firing, and the hint showing/clearing; check-doc-narrative.py --diff origin/main 0 warnings; live-E2E via scripts/e2e-local.sh on port 8440 — server reached readiness, /app/ returned 200, built bundle confirmed to contain the "Autoplay was blocked" hint string, server stopped cleanly. No .cs/scripts//workflow files touched, so the .NET and Python gates don't apply.
Deferred: none.
Docs updated: docs/spa-conventions.md §5b (HlsPlayer's muted attribute and the onAutoplayBlocked contract).

Done-when evidence:

  • "a preview that cannot autoplay either starts anyway or tells the operator what to do": HlsPlayer.tsx renders <video muted> (starts anyway in the common case) and calls onAutoplayBlocked on rejection, wired to the "Autoplay was blocked — press play on the video to start the preview." hint in ChannelPreviewPanel.tsx (residual case).
  • "covered by a web test": web/src/media/HlsPlayer.test.tsx (4 new tests: muted attribute, callback fires on rejection, callback silent on success, safe when omitted) and web/src/screens/channels/ChannelPreviewPanel.test.tsx (3 new tests: hint shown on blocked autoplay, hint clears on playing, hint absent when play() succeeds) — npm test run confirming 1332/1332 passed.
  • "docs/spa-conventions.md §5b updated if HlsPlayer's element attributes change": diff in PR #910 adds the "Autoplay (#554)" subsection to §5b.
  • "adversarial review passed": 1 review round on the branch, findings folded into the diff (see PR #910 body); cross-family review not required (routine risk class under process.independent-review-rubric).
> **SUPERSEDED — do not read this as the outcome.** Replaced by the closing record at #554 (comment 26478). This record describes only the branch's first commit; the `muted`-unconditionally behaviour, the `onPlaying` clear and the "findings folded into the diff" claim below were all reversed or were false. The measurements below are of that first commit. ## Closing record **Outcome:** PR #910 (https://gitea.tblindustries.be/timothy/ersatztv/pulls/910) — `HlsPlayer` now renders `<video>` `muted` unconditionally so autoplay is never blocked in the common case, plus an optional `onAutoplayBlocked()` callback for the residual case (stricter browser policy/extension); `ChannelPreviewPanel` wires it to a "press play" hint shown only while `state` is still `starting`. **Root cause:** `manifestLoadPolicy.maxTimeToFirstByteMs: Infinity` (needed because ErsatzTV's manifest GET blocks until segments exist, #60/PR#551) means `MANIFEST_PARSED` can arrive past the browser's ~5s transient user-activation window on a slow-starting channel, so `video.play()` is rejected as blocked autoplay with no `playing` event and no hint to the operator. **Decisions/conventions changed:** none new — extends the existing `HlsPlayer` optional-callback convention (`onError`/`onPlaying`) documented in `docs/spa-conventions.md` §5b. **Reusable knowledge:** muted autoplay removes the failure mode outright rather than annotating it (per the issue's own analysis) — the residual `onAutoplayBlocked` path exists only for policies stricter than "blocks autoplay of unmuted media", which is the common browser default this fix targets. **Verification:** `npm run check:api && npm run lint && npm run typecheck && npm run build` clean; `npm test` 121 files / 1332 tests passed (2026-09-05), including 4 new `HlsPlayer` tests and 3 new `ChannelPreviewPanel` tests pinning the muted attribute, the callback firing/not-firing, and the hint showing/clearing; `check-doc-narrative.py --diff origin/main` 0 warnings; live-E2E via `scripts/e2e-local.sh` on port 8440 — server reached readiness, `/app/` returned 200, built bundle confirmed to contain the "Autoplay was blocked" hint string, server stopped cleanly. No `.cs`/`scripts/`/workflow files touched, so the .NET and Python gates don't apply. **Deferred:** none. **Docs updated:** `docs/spa-conventions.md` §5b (HlsPlayer's `muted` attribute and the `onAutoplayBlocked` contract). **Done-when evidence:** - "a preview that cannot autoplay either starts anyway or tells the operator what to do": `HlsPlayer.tsx` renders `<video muted>` (starts anyway in the common case) and calls `onAutoplayBlocked` on rejection, wired to the "Autoplay was blocked — press play on the video to start the preview." hint in `ChannelPreviewPanel.tsx` (residual case). - "covered by a web test": `web/src/media/HlsPlayer.test.tsx` (4 new tests: muted attribute, callback fires on rejection, callback silent on success, safe when omitted) and `web/src/screens/channels/ChannelPreviewPanel.test.tsx` (3 new tests: hint shown on blocked autoplay, hint clears on `playing`, hint absent when `play()` succeeds) — `npm test` run confirming 1332/1332 passed. - "docs/spa-conventions.md §5b updated if HlsPlayer's element attributes change": diff in PR #910 adds the "Autoplay (#554)" subsection to §5b. - "adversarial review passed": 1 review round on the branch, findings folded into the diff (see PR #910 body); cross-family review not required (routine risk class under process.independent-review-rubric).
timothy commented 2026-09-05 02:13:52 +02:00
Author
Owner
Copy Link
Copy Source

Closing record (supersedes the record posted 2026-09-05 01:39)

This replaces the earlier closing record on this issue. That one described only the branch's first commit and asserted three things the two later commits reverse: <video> muted unconditionally, a clear in onPlaying, and "1 review round … findings folded into the diff" (at the time, none of round one's findings were in the diff). Its npm test and live-E2E numbers were measurements of that first commit. Everything below is measured on the branch as it stands (3 commits).

Outcome: PR #910 — HlsPlayer takes an optional muted prop, defaulting to false, plus an optional onAutoplayBlocked() callback that fires only on an autoplay-policy rejection (a DOMException named NotAllowedError). The channel-preview panel opts into muted — muted media autoplays without user activation, which removes the failure mode rather than annotating it — and wires onAutoplayBlocked to a "press play" hint for the residual case (a stricter browser policy or an extension). The playback-troubleshooting screen deliberately stays unmuted: verifying the audio side of an FFmpeg profile is part of its job, and the legacy Blazor player was never muted.

Root cause: manifestLoadPolicy.maxTimeToFirstByteMs: Infinity (needed because ErsatzTV's manifest GET blocks until segments exist, #60/PR#551) means MANIFEST_PARSED can arrive past the browser's ~5s transient user-activation window on a slow-starting channel, so video.play() is rejected as blocked autoplay with no playing event and no hint to the operator.

Decisions/conventions changed: none new — extends the existing HlsPlayer optional-callback convention (onError/onPlaying) documented in docs/spa-conventions.md §5b.

Reusable knowledge:

  • Muting is the consumer's call on a shared player, not the player's default: the same attribute that fixes one screen silences another whose purpose is audio.
  • A rejected play() says why in the DOMException name. AbortError (a pending play() interrupted by teardown — exactly what this panel's own Retry produces) is not blocked autoplay, and reporting it as such puts a cause in front of the operator that did not happen. Because the element is muted, a genuine NotAllowedError is the rare case, so the unfiltered firings would have been mostly the mislabelled ones.
  • Dropping a redundant guard moves the burden onto whatever remains: with the onPlaying clear gone, the hint's only guard is state === 'starting', so every path back to starting must clear the flag itself — an invariant that has to be pinned per path, not asserted in prose.

Verification (branch head, 2026-09-05):

  • cd web && npm run check:api && npm run lint && npm run typecheck && npm run build — clean.
  • npm test — 121 test files / 1342 tests passed.
  • Mutation-proof, each mutation caught by exactly one test: deleting setAutoplayBlocked(false) from onRetry → Tests 1 failed | 25 passed; deleting it from the render-phase channel reset → 1 failed | 25 passed; replacing autoplayBlocked && state === 'starting' && with autoplayBlocked && → 1 failed | 25 passed. Unmutated: 26 passed.
  • python3 scripts/check-doc-narrative.py --diff origin/main — 0 advisory warnings.
  • Live-E2E: ETV_UI_PORT=8440 scripts/e2e-local.sh <fresh CONFIG_DIR> — readiness reached, /app/ 200, and the served bundle carries the end state: HlsPlayer compiled as muted:s=!1 rendering muted:s, the preview panel the only call site passing muted:!0, the NotAllowedError filter and the "Autoplay was blocked" string both present. Server stopped by the PID the launcher printed.
  • No .cs, scripts/ or workflow files touched, so the .NET and Python gates do not apply.

Deferred: none.

Docs updated: docs/spa-conventions.md §5b — the muted prop and why it is per-consumer, the NotAllowedError-only contract for onAutoplayBlocked, and the single-guard invariant.

Done-when evidence:

  • A preview that cannot autoplay either starts anyway or tells the operator what to do: the preview passes muted, so the common case starts on its own; when a stricter policy still refuses, onAutoplayBlocked raises "Autoplay was blocked — press play on the video to start the preview." while the panel stays honestly at starting.
  • Covered by a web test: web/src/media/HlsPlayer.test.tsx (the muted prop default and opt-in, the callback firing only on NotAllowedError, silence on AbortError and on success, safe when omitted, and the previously untested native-HLS branch) and web/src/screens/channels/ChannelPreviewPanel.test.tsx (hint shown when blocked, hidden once playing, absent on a non-autoplay rejection, absent when play() succeeds, cleared by Retry, cleared by a channel switch), plus PlaybackTroubleshootingScreen.test.tsx pinning that screen unmuted. Suite: 1342 passed.
  • docs/spa-conventions.md §5b updated if HlsPlayer's element attributes change: the "Autoplay (#554)" subsection in the PR diff.
  • Adversarial review passed: two rounds, each answered by its own commit (round 1 → fix(554): the hint's cause must be measured, and muting is the consumer's call; round 2 → test(554): pin both clears the hint's single guard depends on). Boxes are left unticked pending the verdict on the final head.

Still required before merge: PR #910's head is still the first commit — the two fix commits are on the branch but not yet pushed. Push the branch, then take CI and the review-verdict/h10 status on the pushed head; this record describes that head, not the one the PR currently points at.

🤖 Generated with Claude Code

https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV

## Closing record (supersedes the record posted 2026-09-05 01:39) **This replaces the earlier closing record on this issue.** That one described only the branch's first commit and asserted three things the two later commits reverse: `<video>` muted *unconditionally*, a clear in `onPlaying`, and "1 review round … findings folded into the diff" (at the time, none of round one's findings were in the diff). Its `npm test` and live-E2E numbers were measurements of that first commit. Everything below is measured on the branch as it stands (3 commits). **Outcome:** PR #910 — `HlsPlayer` takes an **optional `muted` prop, defaulting to `false`**, plus an optional `onAutoplayBlocked()` callback that fires **only** on an autoplay-policy rejection (a `DOMException` named `NotAllowedError`). The channel-preview panel opts into `muted` — muted media autoplays without user activation, which removes the failure mode rather than annotating it — and wires `onAutoplayBlocked` to a "press play" hint for the residual case (a stricter browser policy or an extension). The playback-troubleshooting screen deliberately stays unmuted: verifying the audio side of an FFmpeg profile is part of its job, and the legacy Blazor player was never muted. **Root cause:** `manifestLoadPolicy.maxTimeToFirstByteMs: Infinity` (needed because ErsatzTV's manifest GET blocks until segments exist, #60/PR#551) means `MANIFEST_PARSED` can arrive past the browser's ~5s transient user-activation window on a slow-starting channel, so `video.play()` is rejected as blocked autoplay with no `playing` event and no hint to the operator. **Decisions/conventions changed:** none new — extends the existing `HlsPlayer` optional-callback convention (`onError`/`onPlaying`) documented in `docs/spa-conventions.md` §5b. **Reusable knowledge:** - Muting is the *consumer's* call on a shared player, not the player's default: the same attribute that fixes one screen silences another whose purpose is audio. - A rejected `play()` says *why* in the DOMException name. `AbortError` (a pending play() interrupted by teardown — exactly what this panel's own Retry produces) is not blocked autoplay, and reporting it as such puts a cause in front of the operator that did not happen. Because the element is muted, a genuine `NotAllowedError` is the rare case, so the unfiltered firings would have been mostly the mislabelled ones. - Dropping a redundant guard moves the burden onto whatever remains: with the `onPlaying` clear gone, the hint's only guard is `state === 'starting'`, so every path back to `starting` must clear the flag itself — an invariant that has to be pinned per path, not asserted in prose. **Verification** (branch head, 2026-09-05): - `cd web && npm run check:api && npm run lint && npm run typecheck && npm run build` — clean. - `npm test` — **121 test files / 1342 tests passed**. - Mutation-proof, each mutation caught by exactly one test: deleting `setAutoplayBlocked(false)` from `onRetry` → `Tests 1 failed | 25 passed`; deleting it from the render-phase channel reset → `1 failed | 25 passed`; replacing `autoplayBlocked && state === 'starting' &&` with `autoplayBlocked &&` → `1 failed | 25 passed`. Unmutated: `26 passed`. - `python3 scripts/check-doc-narrative.py --diff origin/main` — 0 advisory warnings. - Live-E2E: `ETV_UI_PORT=8440 scripts/e2e-local.sh <fresh CONFIG_DIR>` — readiness reached, `/app/` 200, and the served bundle carries the end state: `HlsPlayer` compiled as `muted:s=!1` rendering `muted:s`, the preview panel the only call site passing `muted:!0`, the `NotAllowedError` filter and the "Autoplay was blocked" string both present. Server stopped by the PID the launcher printed. - No `.cs`, `scripts/` or workflow files touched, so the .NET and Python gates do not apply. **Deferred:** none. **Docs updated:** `docs/spa-conventions.md` §5b — the `muted` prop and why it is per-consumer, the `NotAllowedError`-only contract for `onAutoplayBlocked`, and the single-guard invariant. **Done-when evidence:** - *A preview that cannot autoplay either starts anyway or tells the operator what to do*: the preview passes `muted`, so the common case starts on its own; when a stricter policy still refuses, `onAutoplayBlocked` raises "Autoplay was blocked — press play on the video to start the preview." while the panel stays honestly at `starting`. - *Covered by a web test*: `web/src/media/HlsPlayer.test.tsx` (the `muted` prop default and opt-in, the callback firing only on `NotAllowedError`, silence on `AbortError` and on success, safe when omitted, and the previously untested native-HLS branch) and `web/src/screens/channels/ChannelPreviewPanel.test.tsx` (hint shown when blocked, hidden once `playing`, absent on a non-autoplay rejection, absent when `play()` succeeds, cleared by Retry, cleared by a channel switch), plus `PlaybackTroubleshootingScreen.test.tsx` pinning that screen unmuted. Suite: 1342 passed. - *`docs/spa-conventions.md` §5b updated if `HlsPlayer`'s element attributes change*: the "Autoplay (#554)" subsection in the PR diff. - *Adversarial review passed*: two rounds, each answered by its own commit (round 1 → `fix(554): the hint's cause must be measured, and muting is the consumer's call`; round 2 → `test(554): pin both clears the hint's single guard depends on`). Boxes are left unticked pending the verdict on the final head. **Still required before merge:** PR #910's head is still the first commit — the two fix commits are on the branch but not yet pushed. Push the branch, then take CI and the `review-verdict/h10` status on the pushed head; this record describes that head, not the one the PR currently points at. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV
timothy commented 2026-09-05 03:04:12 +02:00
Author
Owner
Copy Link
Copy Source

This supersedes the earlier ## Closing record comments on this issue (comment ids 26468, 26478)
— both were written against an earlier state of the branch and their counts are stale now that
4e042fb7d, b6b4fb661, f119bfcb2, and 350509f8b have landed on top of 02e1c583e.

Closing record

Outcome: PR #910 (branch 554-preview-autoplay-blocked-hint, head 350509f8b, 5 commits)
mutes the channel-preview player (opt-in muted prop on HlsPlayer, default false) and
filters onAutoplayBlocked to fire only on a DOMException named NotAllowedError, so the
panel shows an explicit "autoplay blocked" hint only when that is actually why playback hasn't
started. Not yet merged.

Root cause: HlsPlayer's <video> played unmuted, and ErsatzTV's manifest GET blocks until
segments exist (manifestLoadPolicy.maxTimeToFirstByteMs: Infinity, inherited from the
troubleshooting-screen use case) — so on a slow-starting channel MANIFEST_PARSED can arrive past
the browser's transient user-activation window, video.play() rejects as blocked autoplay, and
the panel sat at starting over a black frame with no indication the operator just needed to
press play.

Decisions/conventions changed: docs/spa-conventions.md §5b updated to document the opt-in
muted prop, the NotAllowedError-only filter on onAutoplayBlocked, and the hint's single
render guard (autoplayBlocked && state === 'starting') together with the three paths back to
starting (Retry, channel change, the mute opt-in) and why only two of the three need to clear
the flag themselves.

Reusable knowledge: the hint's visibility has exactly one guard
(state === 'starting') — every path that returns the panel to starting is independently
responsible for clearing autoplayBlocked, since nothing else does. The mute opt-in button is
the one path that doesn't clear it and is provably safe not to: the button only renders while
started is false, and started only goes false in the same render-phase reset that clears
the flag two lines later, so no player exists to have set the flag while the button is visible.

Verification (measured on 350509f8b, 2026-09-05):

  • npm run check:api, npm run lint, npm run typecheck, npm run build — all clean.
  • npm test: 121 test files, 1343 tests, all passed.
  • Touched suites individually: HlsPlayer.test.tsx — 15 passed; ChannelPreviewPanel.test.tsx
    — 27 passed; those two plus PlaybackTroubleshootingScreen.test.tsx together — 55 passed.
  • python3 scripts/check-doc-narrative.py --diff origin/main — 0 warnings.
  • Live-E2E: dotnet build ErsatzTV.sln succeeded; ETV_UI_PORT=8440 scripts/e2e-local.sh <fresh mktemp dir> reported "Server ready"; curl /app/ returned HTTP 200; the launched PID
    was killed after the check.
  • Mutation coverage (from b6b4fb661): deleting the Retry-path clear reds exactly the Retry
    test; deleting the render-phase-reset clear reds exactly the channel-change test; widening the
    render guard to drop state === 'starting' reds a third, distinct test.
  • Three review rounds ran on the branch before this push: round one — 1 blocking, 2 should-fix,
    1 nit, answered by 4e042fb7d; round two — 1 should-fix (the opt-in third path), answered by
    f119bfcb2 + 350509f8b; round three — measurement staleness only (this record and the PR
    body), answered by this comment and the PR body rewrite. Cross-family review: not required
    (routine risk class under process.independent-review-rubric).

Deferred: none.

Docs updated: docs/spa-conventions.md §5b (in 4e042fb7d, f119bfcb2).

Done-when evidence

  • A preview that cannot autoplay either starts anyway or tells the operator what to do —
    evidenced by HlsPlayer.tsx's opt-in muted prop + NotAllowedError-filtered
    onAutoplayBlocked, and ChannelPreviewPanel.tsx's hint rendered on
    autoplayBlocked && state === 'starting' (commit 4e042fb7d); confirmed live via the E2E run
    above (/app/ 200 on a built preview panel).
  • Covered by a web test — evidenced by HlsPlayer.test.tsx (15 passed) and
    ChannelPreviewPanel.test.tsx (27 passed, including the two path-specific tests added in
    b6b4fb661 and the opt-in-reachability test added in f119bfcb2), plus the mutation-testing
    results in b6b4fb661's commit message.
  • docs/spa-conventions.md §5b updated if HlsPlayer's element attributes change —
    evidenced by git show --stat 4e042fb7d f119bfcb2 350509f8b -- docs/spa-conventions.md.
  • Adversarial review passed — evidenced by the three review rounds summarized above,
    answered by commits 4e042fb7d, b6b4fb661, f119bfcb2, 350509f8b; no Review-verdict:
    comment / review-verdict/h10 status has been posted yet for this head, which is why this
    box is left unticked and the issue stays open.

None of the four boxes above are being ticked by this comment — that is left for the merge-gate
flow (Review-verdict: + CI) to derive, per process.done-when-boxes-can-be-circular and the
root CLAUDE.md's merge-consent convention.

This supersedes the earlier `## Closing record` comments on this issue (comment ids 26468, 26478) — both were written against an earlier state of the branch and their counts are stale now that `4e042fb7d`, `b6b4fb661`, `f119bfcb2`, and `350509f8b` have landed on top of `02e1c583e`. ## Closing record **Outcome:** PR #910 (branch `554-preview-autoplay-blocked-hint`, head `350509f8b`, 5 commits) mutes the channel-preview player (opt-in `muted` prop on `HlsPlayer`, default `false`) and filters `onAutoplayBlocked` to fire only on a `DOMException` named `NotAllowedError`, so the panel shows an explicit "autoplay blocked" hint only when that is actually why playback hasn't started. Not yet merged. **Root cause:** `HlsPlayer`'s `<video>` played unmuted, and ErsatzTV's manifest GET blocks until segments exist (`manifestLoadPolicy.maxTimeToFirstByteMs: Infinity`, inherited from the troubleshooting-screen use case) — so on a slow-starting channel `MANIFEST_PARSED` can arrive past the browser's transient user-activation window, `video.play()` rejects as blocked autoplay, and the panel sat at `starting` over a black frame with no indication the operator just needed to press play. **Decisions/conventions changed:** `docs/spa-conventions.md` §5b updated to document the opt-in `muted` prop, the `NotAllowedError`-only filter on `onAutoplayBlocked`, and the hint's single render guard (`autoplayBlocked && state === 'starting'`) together with the three paths back to `starting` (Retry, channel change, the mute opt-in) and why only two of the three need to clear the flag themselves. **Reusable knowledge:** the hint's visibility has exactly one guard (`state === 'starting'`) — every path that returns the panel to `starting` is independently responsible for clearing `autoplayBlocked`, since nothing else does. The mute opt-in button is the one path that doesn't clear it and is provably safe not to: the button only renders while `started` is `false`, and `started` only goes `false` in the same render-phase reset that clears the flag two lines later, so no player exists to have set the flag while the button is visible. **Verification (measured on `350509f8b`, 2026-09-05):** - `npm run check:api`, `npm run lint`, `npm run typecheck`, `npm run build` — all clean. - `npm test`: **121 test files, 1343 tests, all passed.** - Touched suites individually: `HlsPlayer.test.tsx` — 15 passed; `ChannelPreviewPanel.test.tsx` — 27 passed; those two plus `PlaybackTroubleshootingScreen.test.tsx` together — 55 passed. - `python3 scripts/check-doc-narrative.py --diff origin/main` — 0 warnings. - Live-E2E: `dotnet build ErsatzTV.sln` succeeded; `ETV_UI_PORT=8440 scripts/e2e-local.sh <fresh mktemp dir>` reported "Server ready"; `curl /app/` returned HTTP 200; the launched PID was killed after the check. - Mutation coverage (from `b6b4fb661`): deleting the Retry-path clear reds exactly the Retry test; deleting the render-phase-reset clear reds exactly the channel-change test; widening the render guard to drop `state === 'starting'` reds a third, distinct test. - Three review rounds ran on the branch before this push: round one — 1 blocking, 2 should-fix, 1 nit, answered by `4e042fb7d`; round two — 1 should-fix (the opt-in third path), answered by `f119bfcb2` + `350509f8b`; round three — measurement staleness only (this record and the PR body), answered by this comment and the PR body rewrite. Cross-family review: not required (routine risk class under `process.independent-review-rubric`). **Deferred:** none. **Docs updated:** `docs/spa-conventions.md` §5b (in `4e042fb7d`, `f119bfcb2`). ## Done-when evidence - [ ] A preview that cannot autoplay either starts anyway or tells the operator what to do — evidenced by `HlsPlayer.tsx`'s opt-in `muted` prop + `NotAllowedError`-filtered `onAutoplayBlocked`, and `ChannelPreviewPanel.tsx`'s hint rendered on `autoplayBlocked && state === 'starting'` (commit `4e042fb7d`); confirmed live via the E2E run above (`/app/` 200 on a built preview panel). - [ ] Covered by a web test — evidenced by `HlsPlayer.test.tsx` (15 passed) and `ChannelPreviewPanel.test.tsx` (27 passed, including the two path-specific tests added in `b6b4fb661` and the opt-in-reachability test added in `f119bfcb2`), plus the mutation-testing results in `b6b4fb661`'s commit message. - [ ] `docs/spa-conventions.md` §5b updated if `HlsPlayer`'s element attributes change — evidenced by `git show --stat 4e042fb7d f119bfcb2 350509f8b -- docs/spa-conventions.md`. - [ ] Adversarial review passed — evidenced by the three review rounds summarized above, answered by commits `4e042fb7d`, `b6b4fb661`, `f119bfcb2`, `350509f8b`; no `Review-verdict:` comment / `review-verdict/h10` status has been posted yet for this head, which is why this box is left unticked and the issue stays open. None of the four boxes above are being ticked by this comment — that is left for the merge-gate flow (`Review-verdict:` + CI) to derive, per `process.done-when-boxes-can-be-circular` and the root `CLAUDE.md`'s merge-consent convention.
timothy removed the in-progress label 2026-09-05 04:23:16 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
ad-hoc
One-off / ad-hoc work not tracked by a dedicated issue
 api
REST API / HTTP endpoints
 bug
Something isn't working
 ci-cd
Build, test, deploy pipeline
 content
Channel content / schedules / playlists
 dependencies
Dependency updates (Renovate)
 enhancement
New feature or improvement
 frontend
ChicoryTV React SPA frontend
 in-progress
Claimed by an active session — do not pick up
 jellyfin
Jellyfin tuner / IPTV integration
 parked
Excluded from automatic queue pickup; work only when explicitly selected
 priority: high
priority: low
priority: medium
review
Adversarial review finding
 security
Security / vulnerability fix
No labels frontend priority: low
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
renovate timothy (Timothy)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: timothy/ersatztv#554