Repository navigation
Stopping Record while a stream stays up leaves recording status stuck at "stopping" (encoder restart erases the finalize result) #466
Description
Found by the T1.8 re-review (2026-09-10), by reading the native code. Pre-existing core defect; not caused by T1.8.
Operator symptom: with Record and Stream both running, stop Record only. recording.status then reads "stopping" until the next recording starts, and there is no terminal lifecycle (completed / failed). The shell and the support bundle can never say whether the file finalized. The file IS finalized (the Stop barrier is FIFO ahead of the new Start), so nothing is lost. What breaks is the truthful-lifecycle contract (CLAUDE.md, "Destination lifecycle is TRUTHFUL").
Mechanism:
- The stop sync carries
stop-recording-session, followed bystart-program-output{destinations:[rtmp…]}without"recording". MediaCore.cpp:2363-2370sees that the start is no longer owned by the recording (recordingStatus_is"stopping"), so it callsencoder->start([rtmp]).- That bumps the sink generation.
AsyncEncoderSink.cpp:117-132resets the snapshot with no recording lifecycle. - The old generation's Stop barrier finalizes the file, but it never publishes
completed(AsyncEncoderSink.cpp:659).
Fix options (core):
- Keep the
"recording"lifecycle across a non-recording Start until its Stop barrier has published. - Or don't treat
"stopping"as released instartProgramOutput.
Related: T1.8 (#461) works around this on app close by stopping streams before recording. That workaround doesn't cover an operator stopping Record alone mid-show.
Activity
iamfatness commentedon Sep 11, 2026
Another case the T1.8 workaround doesn't cover, from its fix round 2: if a stream START is still in flight when the app closes, the stream stop is ignored. The recording stop then goes out while streaming is still desired, so the encoder restarts again and the close waits the full 15 s. The file is still finalized. Only the core fix above closes every case.
iamfatness commentedon Sep 11, 2026
Seen live during the T1.8 check (2026-09-10): a fresh core where recording was never started reports
recording: {status: "stopping", writerStatus: "finalizing", lifecycle: null, sessionId: "native-recording-session"}as soon as a stream-only start runs. Same projection bug: the stream's encoder start leaves the recording fields reading a finalize that never happened. The T1.8 close guard correctly ignores it (the dialog said "Streaming to 1 destination"), but anything that showsrecording.status(the UI, the support bundle) will show a phantom finalizing recording.docs(backlog): record the 2026-09-12 batch (#506)