M2-02: Playback — hear a memo #29

New issue

Closed

opened 2026-08-08 19:56:51 -04:00 by agent · 0 comments

agent commented

2026-08-08 19:56:51 -04:00

Member

Play a memo back from its detail view. Play, pause, scrub, elapsed and remaining.

Why

M1 produces audio nobody has heard inside the app. Confirming a memo recorded is currently a
matter of trusting the file size, or pulling it off the phone and playing it somewhere else.
M2-01 (#27) shows what the speech engine heard; this shows what the microphone got, which is the
other half of trusting the recording.

Scope

A transport in the memo detail view: play/pause, a scrubber, elapsed and remaining time.
Duration comes from the asset, the same reading the list row already does.
The scrubber seeks, and dragging it does not fight the playhead updating underneath.

Playback is blocked while a recording is running

Decided 2026-08-08. The audio session is configured for capture, and reconfiguring it
mid-recording is the class of change that broke v2. Tapping play during a recording says why
rather than showing a transport that does nothing, or worse, one that disturbs the capture.

That means the session category has to be handed between the two modes deliberately, and coming
back from playback must leave capture able to start again. A recording that will not start
because a playback left the session in the wrong category is the failure this issue can
introduce, and it is what the device test below is for.

The audio may not be playable

A capture killed mid-recording is playable up to the last fragment flush — that is what
movieFragmentInterval buys — but a file truncated by a full disk, or replaced by hand through
the Files app now that #12 opened the directory, may not decode at all. That fails out loud with
a reason. A dead transport that never starts is the wrong answer.

Not in this

No lock screen or Control Center playback controls, no MPNowPlayingInfoCenter, no background
playback. This is playback while looking at the memo. Background audio is a category the app
already declares for recording, and extending it to playback is a separate decision.

Done when

A memo recorded on a previous launch plays, pauses, and scrubs.
Tapping play during a recording says why it will not play.
After playing a memo, starting a new recording still works.
A memo whose audio cannot be decoded says so.

Milestone 2 of the Stash v3 rebuild. M2 is still app-side — no sync, no account, no server. It
turns a list of memos into something you can open, listen to, read and see the route of. Sync
arrives in M3. There is no milestone/M2 label yet (creating org labels needs owner rights), so
the title carries the milestone.

Working agreement for every issue in this repo: feature branch, tested before the PR opens
(on-device where the label says so), then Wes reviews the PR and we walk the code together. Docs
update in the same commit. A PR that takes more than 20 minutes to review is too big — say so and
split it.

Play a memo back from its detail view. Play, pause, scrub, elapsed and remaining. ## Why M1 produces audio nobody has heard inside the app. Confirming a memo recorded is currently a matter of trusting the file size, or pulling it off the phone and playing it somewhere else. M2-01 (#27) shows what the speech engine heard; this shows what the microphone got, which is the other half of trusting the recording. ## Scope - A transport in the memo detail view: play/pause, a scrubber, elapsed and remaining time. - Duration comes from the asset, the same reading the list row already does. - The scrubber seeks, and dragging it does not fight the playhead updating underneath. ## Playback is blocked while a recording is running **Decided 2026-08-08.** The audio session is configured for capture, and reconfiguring it mid-recording is the class of change that broke v2. Tapping play during a recording says why rather than showing a transport that does nothing, or worse, one that disturbs the capture. That means the session category has to be handed between the two modes deliberately, and coming back from playback must leave capture able to start again. A recording that will not start because a playback left the session in the wrong category is the failure this issue can introduce, and it is what the device test below is for. ## The audio may not be playable A capture killed mid-recording is playable up to the last fragment flush — that is what `movieFragmentInterval` buys — but a file truncated by a full disk, or replaced by hand through the Files app now that #12 opened the directory, may not decode at all. That fails out loud with a reason. A dead transport that never starts is the wrong answer. ## Not in this No lock screen or Control Center playback controls, no `MPNowPlayingInfoCenter`, no background playback. This is playback while looking at the memo. Background audio is a category the app already declares for *recording*, and extending it to playback is a separate decision. ## Done when - [ ] A memo recorded on a previous launch plays, pauses, and scrubs. - [ ] Tapping play during a recording says why it will not play. - [ ] After playing a memo, starting a new recording still works. - [ ] A memo whose audio cannot be decoded says so. --- *Milestone 2 of the Stash v3 rebuild. M2 is still app-side — **no sync, no account, no server**. It turns a list of memos into something you can open, listen to, read and see the route of. Sync arrives in M3. There is no `milestone/M2` label yet (creating org labels needs owner rights), so the title carries the milestone.* *Working agreement for every issue in this repo: feature branch, tested before the PR opens (on-device where the label says so), then Wes reviews the PR and we walk the code together. Docs update in the same commit. A PR that takes more than 20 minutes to review is too big — say so and split it.*

agent added the

labels

2026-08-08 19:56:51 -04:00

agent referenced this issue from a pull request that will close it,

2026-08-09 15:00:36 -04:00

M2-02: Playback — hear a memo #42