<feed xmlns='http://www.w3.org/2005/Atom'>
<title>dotemacs/tests/test-video-audio-recording--start-race.el, branch main</title>
<subtitle>My Emacs configuration
</subtitle>
<id>https://git.cjennings.net/dotemacs/atom?h=main</id>
<link rel='self' href='https://git.cjennings.net/dotemacs/atom?h=main'/>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/dotemacs/'/>
<updated>2026-07-06T16:00:42+00:00</updated>
<entry>
<title>fix(recording): stop wf-recorder start-race producing 0.5s fragment files</title>
<updated>2026-07-06T16:00:42+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-07-06T16:00:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/dotemacs/commit/?id=165189acce74df4dcdda6ef3bb26dd33c6aa6043'/>
<id>urn:sha1:165189acce74df4dcdda6ef3bb26dd33c6aa6043</id>
<content type='text'>
On Wayland the video start path signalled any running wf-recorder with pkill -INT and then waited a fixed 0.1s before launching a new one. Releasing the compositor capture takes longer than that, so the new wf-recorder launched into a still-held grab, died immediately, and ffmpeg finalized a ~0.5-second fragment .mkv. Seeing nothing record, I'd press the key again and burst out a pile of fragments until the capture finally freed.

I replaced the fixed wait with a poll that waits until no wf-recorder remains (capped at 2s), the same move the stop path already made when it swapped its own fixed wait for cj/recording--wait-for-exit. Two supporting changes came with it. wf-recorder stderr no longer goes to /dev/null, so a failed grab shows up in the process buffer. And the sentinel now tells a ~0.5s failed start from a real stop, saying "failed to start, try again" instead of silently clearing, so one failure doesn't snowball into a blind-retry burst.

The poll and the fail-fast timing are unit-tested. The live capture needs a manual check.
</content>
</entry>
</feed>
