Phone follows a live Playback Session and shows its Playhead #3

New issue

Closed

opened 2026-08-09 20:42:19 +00:00 by aiko · 2 comments

aiko commented

2026-08-09 20:42:19 +00:00

Owner

Parent

#1 — PRD: Kurageyomi

What to build

The phone follows a live Playback Session and displays its Playhead.

Add a SessionWatcher that resolves which Playback Sessions belong to the requesting user and
exposes each one's Playhead, item, and stream indices. The page subscribes to session state and
shows the Playhead updating as an episode plays. Raw ticks on screen is a perfectly good demo
for this slice — no Cues yet.

Selection behaviour: exactly one playing Playback Session is followed automatically; more than
one shows a picker; whichever was picked is remembered for next time.

Note the cadence this has to live with, because it shapes everything downstream. Clients report
progress on a 10-second throttle while playing, but report immediately on pause,
unpause, and any seek beyond roughly 5 seconds of drift. The server does not extrapolate — the
Playhead it reports is simply the last value a client sent. Subscribing to the server's session
push more often than every 10 seconds does not get fresher numbers; it gets the same number
repeated, and fast notification of pause and seek. Do not paper over this here by interpolating
— that is #5's job, and it needs the raw reports to be visibly raw.

Acceptance criteria

An authenticated endpoint lists the requesting user's active Playback Sessions
The page displays the followed Playback Session's Playhead, updating as reports arrive
A single playing Playback Session is selected with no interaction
Two or more playing Playback Sessions present a picker
The last picked Playback Session is remembered across page reloads
Pausing on the client is reflected on the phone promptly, not on the next 10-second tick
The page recovers when the followed Playback Session ends or disappears

Blocked by

## Parent #1 — PRD: Kurageyomi ## What to build The phone follows a live Playback Session and displays its Playhead. Add a `SessionWatcher` that resolves which Playback Sessions belong to the requesting user and exposes each one's Playhead, item, and stream indices. The page subscribes to session state and shows the Playhead updating as an episode plays. Raw ticks on screen is a perfectly good demo for this slice — no Cues yet. Selection behaviour: exactly one playing Playback Session is followed automatically; more than one shows a picker; whichever was picked is remembered for next time. Note the cadence this has to live with, because it shapes everything downstream. Clients report progress on a **10-second throttle** while playing, but report **immediately** on pause, unpause, and any seek beyond roughly 5 seconds of drift. The server does not extrapolate — the Playhead it reports is simply the last value a client sent. Subscribing to the server's session push more often than every 10 seconds does not get fresher numbers; it gets the same number repeated, and fast notification of pause and seek. Do not paper over this here by interpolating — that is #5's job, and it needs the raw reports to be visibly raw. ## Acceptance criteria - [ ] An authenticated endpoint lists the requesting user's active Playback Sessions - [ ] The page displays the followed Playback Session's Playhead, updating as reports arrive - [ ] A single playing Playback Session is selected with no interaction - [ ] Two or more playing Playback Sessions present a picker - [ ] The last picked Playback Session is remembered across page reloads - [ ] Pausing on the client is reflected on the phone promptly, not on the next 10-second tick - [ ] The page recovers when the followed Playback Session ends or disappears ## Blocked by - #2

aiko added the

ready-for-agent

label

2026-08-09 20:42:19 +00:00

aiko referenced this issue

2026-08-09 20:42:21 +00:00

PlayheadClock: transcript follows the show #5

aiko referenced this issue from a commit

2026-08-09 23:11:14 +00:00

fix: separate data endpoints from the asset route

aiko referenced this issue from a commit

2026-08-09 23:11:14 +00:00

feat: read subtitle tracks as Cues and show the transcript

aiko commented

2026-08-09 23:11:54 +00:00

Author

Owner

This was generated by AI during triage.

Implemented and merged to main at c8440ee. Held open deliberately: the code is unit-tested but has never run on the real server, and this issue's criteria include behaviour only observable there. #6 deploys it; this closes once that confirms it.

> *This was generated by AI during triage.* Implemented and merged to `main` at `c8440ee`. Held open deliberately: the code is unit-tested but has never run on the real server, and this issue's criteria include behaviour only observable there. #6 deploys it; this closes once that confirms it.

aiko commented

2026-08-10 08:03:48 +00:00

Author

Owner

This was generated by AI during triage.

Verified on dionysus: sign-in works from the phone, the playing Playback Session is followed with no interaction, and its Playhead updates. Merged in main.

One deployment-time fix this needed: crypto.randomUUID is undefined outside a secure context, so device id generation crashed sign-in over http. Device ids now come from crypto.getRandomValues, with tests.

Follow-up filed as #7 — pause and unpause lag by up to a poll interval, which the session WebSocket removes.

> *This was generated by AI during triage.* Verified on dionysus: sign-in works from the phone, the playing Playback Session is followed with no interaction, and its Playhead updates. Merged in `main`. One deployment-time fix this needed: `crypto.randomUUID` is undefined outside a secure context, so device id generation crashed sign-in over http. Device ids now come from `crypto.getRandomValues`, with tests. Follow-up filed as #7 — pause and unpause lag by up to a poll interval, which the session WebSocket removes.

aiko closed this issue

2026-08-10 08:03:48 +00:00