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

Auto-pause, and letting the show follow the phone #18

New issue
Closed
opened 2026-08-10 12:43:34 +00:00 by aiko · 1 comment
aiko commented 2026-08-10 12:43:34 +00:00
Owner
Copy link

Parent

#1

What to build

Two behaviours, both settings-gated, both built on PlaybackRemote. Read docs/adr/0008-the-show-can-follow-the-phone.md first — it is the decision record for the second one and it amends ADR 0007.

Auto-pause (PRD stories 13 and 14, on by default). Tapping a word pauses the Playback Session; dismissing the Lookup resumes it. Both produce an immediate progress report from the client, which resyncs the Playhead as a side effect — so this makes the transcript more accurate, not less. Only resume what you paused: if the show was already paused when you tapped, dismissing must leave it paused.

Swiping seeks the show (off by default). The Playback Session seeks to whatever Cue the reader lands on.

Two consequences that are the design, not edge cases:

  • Frozen cannot occur while it is on. You cannot be out of sync with something chasing you, so the frozen strip and both jump controls disappear. This changes the shape of the screen, so which mode is active has to be legible without opening settings.
  • It seeks where you land, not through what you pass. One seek, on settle, debounced. A fast swipe across eight Cues that queued eight seeks would leave the television buffering through all of them — and other people use this server.

Acceptance criteria

  • With auto-pause on, tapping a word pauses and dismissing resumes
  • A show already paused before the tap is still paused after the dismissal
  • With auto-pause off, tapping a word does not touch playback
  • With follow on, settling on a Cue seeks the Playback Session to its start
  • A fast swipe across many Cues issues one seek, not one per Cue
  • With follow on, the frozen strip and both jump controls are absent
  • Turning follow off mid-episode restores the frozen state without a reload
  • Which mode is active is legible on the watching screen, not only in settings
  • The debounce, the pause/resume pairing, and the already-paused case are covered by tests

Blocked by

## Parent #1 ## What to build Two behaviours, both settings-gated, both built on `PlaybackRemote`. Read `docs/adr/0008-the-show-can-follow-the-phone.md` first — it is the decision record for the second one and it amends ADR 0007. **Auto-pause** (PRD stories 13 and 14, on by default). Tapping a word pauses the Playback Session; dismissing the Lookup resumes it. Both produce an immediate progress report from the client, which resyncs the Playhead as a side effect — so this makes the transcript more accurate, not less. Only resume what you paused: if the show was already paused when you tapped, dismissing must leave it paused. **Swiping seeks the show** (off by default). The Playback Session seeks to whatever Cue the reader lands on. Two consequences that are the design, not edge cases: - **Frozen cannot occur while it is on.** You cannot be out of sync with something chasing you, so the frozen strip and both jump controls disappear. This changes the shape of the screen, so which mode is active has to be legible without opening settings. - **It seeks where you land, not through what you pass.** One seek, on settle, debounced. A fast swipe across eight Cues that queued eight seeks would leave the television buffering through all of them — and other people use this server. ## Acceptance criteria - [ ] With auto-pause on, tapping a word pauses and dismissing resumes - [ ] A show already paused before the tap is still paused after the dismissal - [ ] With auto-pause off, tapping a word does not touch playback - [ ] With follow on, settling on a Cue seeks the Playback Session to its start - [ ] A fast swipe across many Cues issues one seek, not one per Cue - [ ] With follow on, the frozen strip and both jump controls are absent - [ ] Turning follow off mid-episode restores the frozen state without a reload - [ ] Which mode is active is legible on the watching screen, not only in settings - [ ] The debounce, the pause/resume pairing, and the already-paused case are covered by tests ## Blocked by - #16 - #17
aiko commented 2026-08-10 16:21:26 +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.

Auto-pause on tap, and the setting that lets the show follow the phone.

Only resumes what it paused — a show already paused when you tapped stays paused. Follow mode seeks where you land, not through what you pass, debounced, because eight queued seeks would leave the television buffering through all of them.

Which mode is active is stated on the watching screen in both positions, not only when on: turning it on removes the frozen strip and both its controls, and a reader who never opens settings should not have to swipe away from live to find out which shape the screen is in.

> *This was generated by AI during triage.* Merged to `main` in af73452. Suites at merge: 79 C#, 335 phone. Auto-pause on tap, and the setting that lets the show follow the phone. Only resumes what it paused — a show already paused when you tapped stays paused. Follow mode seeks where you land, not through what you pass, debounced, because eight queued seeks would leave the television buffering through all of them. Which mode is active is stated on the watching screen in both positions, not only when on: turning it on removes the frozen strip and both its controls, and a reader who never opens settings should not have to swipe away from live to find out which shape the screen is in.
aiko closed this issue 2026-08-10 16:21:26 +00:00
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#18
No description provided.