mobrule/kurageyomi
3
0
Fork 0
Code Issues 5 Pull requests Projects Releases Packages Wiki Activity Actions

Scrubbing back a Cue at a time actually works #21

New issue
Closed
opened 2026-08-10 14:23:07 +00:00 by aiko · 1 comment
aiko commented 2026-08-10 14:23:07 +00:00
Owner
Copy link

Parent

#1

What is wrong

From a real episode: "If I tap scrub left twice quickly it should go further back, and then every following tap should go back a line too. At the moment it's really hard to navigate back."

Two causes, and both need fixing:

The Playhead does not move when we seek. The phone interpolates position from the client's last progress report. After our own seek it keeps interpolating from the old report until the client sends a new one — up to ten seconds. So a second ⏮ computes from a stale position and seeks to the same place again. showJumpedToPanel already does the equivalent optimistic update for the strip; the Playhead needs the same treatment when we seek it ourselves.

One replay is right; a run of taps is not. previousCueStart replays the Cue being spoken, and a REPLAY_GRACE_TICKS window makes a second press step back. That is the correct first press and the wrong third, fourth and fifth. Repeated presses in quick succession should each go one Cue further back, the way skip-back works on any media remote — the run continues from where the last press landed, not from wherever the Playhead has drifted to.

The first press keeping its "replay this line" behaviour is deliberate and should stay: it is the single most useful press in a mining session.

Acceptance criteria

  • After a seek, the app's Playhead reflects the new position immediately rather than waiting for the client to report
  • First ⏮ replays the Cue being spoken
  • A run of ⏮ presses steps one Cue further back per press, from where the previous press landed
  • The run ends after a pause, and the next press replays the current Cue again
  • ⏭ behaves consistently with the same run rule
  • A run that reaches the first Cue stops there rather than seeking off the front
  • The run and the optimistic Playhead update are covered by tests, including that a run of three presses lands three Cues back

Blocked by

## Parent #1 ## What is wrong From a real episode: *"If I tap scrub left twice quickly it should go further back, and then every following tap should go back a line too. At the moment it's really hard to navigate back."* Two causes, and both need fixing: **The Playhead does not move when we seek.** The phone interpolates position from the client's last progress report. After our own seek it keeps interpolating from the *old* report until the client sends a new one — up to ten seconds. So a second `⏮` computes from a stale position and seeks to the same place again. `showJumpedToPanel` already does the equivalent optimistic update for the strip; the Playhead needs the same treatment when we seek it ourselves. **One replay is right; a run of taps is not.** `previousCueStart` replays the Cue being spoken, and a `REPLAY_GRACE_TICKS` window makes a second press step back. That is the correct first press and the wrong third, fourth and fifth. Repeated presses in quick succession should each go one Cue further back, the way skip-back works on any media remote — the run continues from where the last press landed, not from wherever the Playhead has drifted to. The first press keeping its "replay this line" behaviour is deliberate and should stay: it is the single most useful press in a mining session. ## Acceptance criteria - [ ] After a seek, the app's Playhead reflects the new position immediately rather than waiting for the client to report - [ ] First `⏮` replays the Cue being spoken - [ ] A run of `⏮` presses steps one Cue further back per press, from where the previous press landed - [ ] The run ends after a pause, and the next press replays the current Cue again - [ ] `⏭` behaves consistently with the same run rule - [ ] A run that reaches the first Cue stops there rather than seeking off the front - [ ] The run and the optimistic Playhead update are covered by tests, including that a run of three presses lands three Cues back ## Blocked by - #16
aiko closed this issue 2026-08-10 16:20:44 +00:00
aiko commented 2026-08-10 16:21:27 +00:00
Author
Owner
Copy link

This was generated by AI during triage.

Merged to main in af73452. Suites at merge: 79 C#, 335 phone.

Scrubbing back actually works. Two causes: the Playhead did not move when we seeked, so a second press computed from a stale position and seeked to the same place; and one replay was right but a run of taps was not.

It found a deeper bug on the way. The app polls every 2s while clients report every 10s, so the clock re-anchored to the same report five times per cycle — pegging the Playhead to a position up to ten seconds old whether or not anything had seeked. An echo is no longer treated as news, with a 15-second guard so a seek that never landed cannot leave the phone lying.

REPLAY_GRACE_TICKS is deleted: where a single press lands no longer depends on how long the reader took over it.

> *This was generated by AI during triage.* Merged to `main` in af73452. Suites at merge: 79 C#, 335 phone. Scrubbing back actually works. Two causes: the Playhead did not move when we seeked, so a second press computed from a stale position and seeked to the same place; and one replay was right but a run of taps was not. It found a deeper bug on the way. The app polls every 2s while clients report every 10s, so the clock re-anchored to the same report five times per cycle — pegging the Playhead to a position up to ten seconds old whether or not anything had seeked. An echo is no longer treated as news, with a 15-second guard so a seek that never landed cannot leave the phone lying. `REPLAY_GRACE_TICKS` is deleted: where a single press lands no longer depends on how long the reader took over it.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
needs-info
Waiting on reporter

  
needs-triage
Maintainer needs to evaluate

  
ready-for-agent
Fully specified, AFK-ready

  
ready-for-human
Needs human implementation

  
wontfix
Will not be actioned

No labels
needs-info
needs-triage
ready-for-agent
ready-for-human
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
mobrule/kurageyomi#21
No description provided.