A report older than our own seek is not news #25

New issue

Closed

opened 2026-08-11 21:01:25 +00:00 by aiko · 1 comment

aiko commented

2026-08-11 21:01:25 +00:00

Owner

Parent

What is wrong, with evidence

Pressing back twice goes back one Cue, then forward one. #21 attempted this and missed. The diagnostics from #24 caught it on a real episode; this is the log, oldest first:

run started previous
seek 304.0
report 305.0  +0.83s off  news
press previous
seek 300.8                       <- went back, correctly
report 299.0  -2.00s off  resync <- stale report lands
run ended resync                 <- run killed by it
report 304.0  +4.94s off  resync <- clock dragged forward to 304
press previous
seek 304.0                       <- "back" now seeks forward

After a seek, the client's in-flight progress reports still describe where it was. They are not identical to the previous report — time has passed, so the position differs — so #21's echo suppression does not catch them. They are classified resync, which both ends the run and drags the clock forward to a pre-seek position. The next press computes "previous Cue" from there and seeks forward.

The flaw is that echo suppression compares values when the question is age. A report that predates the seek is stale whatever it says.

What to build

A pending-seek gate. Once the app seeks, a report is not trusted until one of:

it corroborates the seek — its position is near the target, so the client has evidently taken it; or
SEEK_CONFIRMATION_MS expires, which #21 already has for the case where the seek never landed.

Until then a report neither resyncs the clock nor ends the run. The existing timeout stays as the backstop against a seek that is silently refused: the phone must never be able to lie forever about where the show is.

Do not merely widen the resync tolerance. The log shows a report +4.94s off, so any tolerance loose enough to swallow it would also swallow a real seek someone made on the television, which is one of the things the run is supposed to notice.

Acceptance criteria

A report that predates a seek does not resync the clock and does not end the run
A report that corroborates the seek is accepted, and the run survives it
A seek the client never takes still corrects itself once the existing timeout expires
A genuine seek on the television still ends the run
Two back presses in quick succession land two Cues back, driven through a real clock with stale reports interleaved as the log shows
The interleaving from the log above is a regression test

Blocked by

## Parent #1 ## What is wrong, with evidence Pressing back twice goes back one Cue, then forward one. #21 attempted this and missed. The diagnostics from #24 caught it on a real episode; this is the log, oldest first: ``` run started previous seek 304.0 report 305.0 +0.83s off news press previous seek 300.8 <- went back, correctly report 299.0 -2.00s off resync <- stale report lands run ended resync <- run killed by it report 304.0 +4.94s off resync <- clock dragged forward to 304 press previous seek 304.0 <- "back" now seeks forward ``` After a seek, the client's in-flight progress reports still describe where it *was*. They are not identical to the previous report — time has passed, so the position differs — so #21's echo suppression does not catch them. They are classified `resync`, which both **ends the run** and **drags the clock forward** to a pre-seek position. The next press computes "previous Cue" from there and seeks forward. **The flaw is that echo suppression compares values when the question is age.** A report that predates the seek is stale whatever it says. ## What to build A pending-seek gate. Once the app seeks, a report is not trusted until one of: - it corroborates the seek — its position is near the target, so the client has evidently taken it; or - `SEEK_CONFIRMATION_MS` expires, which #21 already has for the case where the seek never landed. Until then a report neither resyncs the clock nor ends the run. The existing timeout stays as the backstop against a seek that is silently refused: the phone must never be able to lie forever about where the show is. Do not merely widen the resync tolerance. The log shows a report `+4.94s` off, so any tolerance loose enough to swallow it would also swallow a real seek someone made on the television, which is one of the things the run is supposed to notice. ## Acceptance criteria - [ ] A report that predates a seek does not resync the clock and does not end the run - [ ] A report that corroborates the seek is accepted, and the run survives it - [ ] A seek the client never takes still corrects itself once the existing timeout expires - [ ] A genuine seek on the television still ends the run - [ ] Two back presses in quick succession land two Cues back, driven through a real clock with stale reports interleaved as the log shows - [ ] The interleaving from the log above is a regression test ## Blocked by - #21 - #24

aiko added the

ready-for-agent

label

2026-08-11 21:01:25 +00:00

aiko referenced this issue from a commit

2026-08-11 21:14:34 +00:00

merge: a report older than our own seek is not news (#25)

aiko referenced this issue

2026-08-11 21:14:52 +00:00

Make the phone say what it thinks is happening #24

aiko commented

2026-08-11 21:14:53 +00:00

Author

Owner

This was generated by AI during triage.

Merged to main. Suites: 79 C#, 366 phone.

Proven by #24's log rather than inferred, and reproduced red before anything was fixed: expected 3040000000 to be 2960000000 — the third press seeking forward, exactly as reported.

After a seek, the client's in-flight reports still describe where it was. They are not identical to the previous report, so #21's echo suppression did not catch them; they were classified resync, which both ended the run and dragged the clock forward to a pre-seek position. Echo suppression compared values when the question was age.

A report is now withheld while a seek is unconfirmed unless it corroborates the seek or the reader's paused state changed. The existing 15s timeout stays as the backstop, so a seek the client silently refuses still corrects itself.

Known consequence, accepted: a genuine seek made on the television within 15s of a phone press is withheld until the window expires. The phone cannot tell it from an in-flight stale report.

> *This was generated by AI during triage.* Merged to `main`. Suites: 79 C#, 366 phone. Proven by #24's log rather than inferred, and reproduced red before anything was fixed: `expected 3040000000 to be 2960000000` — the third press seeking forward, exactly as reported. After a seek, the client's in-flight reports still describe where it was. They are not identical to the previous report, so #21's echo suppression did not catch them; they were classified `resync`, which both ended the run and dragged the clock forward to a pre-seek position. **Echo suppression compared values when the question was age.** A report is now withheld while a seek is unconfirmed unless it corroborates the seek or the reader's paused state changed. The existing 15s timeout stays as the backstop, so a seek the client silently refuses still corrects itself. Known consequence, accepted: a genuine seek made on the television within 15s of a phone press is withheld until the window expires. The phone cannot tell it from an in-flight stale report.

aiko closed this issue

2026-08-11 21:14:53 +00:00