Repository navigation
Screen recording: stopping twice posts two "saved" toasts and a broken thumbnail #11508
Description
System details
Omarchy 4.0.3 (current quattro has the same stop_screenrecording), gpu-screen-recorder 6.1.0, iMac18,3 with a Radeon Pro 575.
What's wrong?
When gpu-screen-recorder takes a moment to exit after SIGINT (a slower encoder draining its queue: 2–3 s at 4K on this Radeon), a second stop runs stop_screenrecording again while the first is still waiting. That happens when you press Alt+Print again, or pick "Stop Screenrecording", because nothing seemed to happen:
- Both calls read
/tmp/omarchy-screenrecord-filenamebefore either removes it, so both runfinalize_recordingand both post "Screen recording saved" for the same file. Their cleanups race over<name>-preview.png, and the toast shows Qt's broken-image placeholder (magenta and black squares); the shell log hasCould not load icon ".../screenrecording-…-preview.png". - If the second stop starts after the first has removed that file, it reads an empty name, and the toast's image is
-preview.png(shell log:Could not load icon "-preview.png"). - If the drain takes longer than the 5 s wait, the second call force-kills the recorder ("Recording process had to be force-killed").
To reproduce (the drain only has to take a moment):
omarchy-capture-screenrecording --fullscreen --resolution=3840x2160
sleep 5
omarchy-capture-screenrecording --stop-recording & sleep 0.4; omarchy-capture-screenrecording --stop-recordingTwo "Screen recording saved" toasts appear for one file, one with a broken thumbnail.
A possible fix: make stopping single-flight, for example exec 9>/tmp/omarchy-screenrecord.lock; flock -n 9 || return 0 at the top of stop_screenrecording, and skip the finalize and notification when the recording file name is empty.
Activity
test(capture): pin single-flight screen recording stop mechanics (oma…
omarchybot commentedon Oct 11, 2026
I reproduced this on a disposable Omarchy worker, and current
quattroalready fixes what you reported. The fix isn't in a release yet.Reproduction. I stubbed a recorder that keeps draining after SIGINT, then ran two
--stop-recordingcalls 0.4s apart. With a 1.5s drain, v4.0.3 posts two "Screen recording saved" toasts for one file. With a 0.5s drain, the second toast's image is-preview.png, as you describe. Currentquattro(9480d1b) posts one toast with the right image in both cases.Why
quattrois fixed. e1b0e5e (#14431) runs the whole ofomarchy-capture-screenrecordingunder oneflock. A second stop waits for the first to finish, finds no recorder and exits. It no longer finalizes the same file a second time or kills a recorder that's still draining. v4.0.4 doesn't include it yet.One path to the empty-name toast is still open, and #15073 fixes it. Without a saved pid, stop picks whatever recorder you're running. Stopping a recorder this script didn't start still posted "saved" with the
-preview.pngimage. #15073 skips the finalize step and the toast when no recording file is known. On the worker, its test fails onquattroand passes with the fix, and the CLI tests and everyscreenrecording-*shell test pass.A change in behaviour the maintainer should weigh. On
quattro, pressing Alt+Print a second time while a slow stop is still draining no longer stops the recording a second time. The press waits until the first stop is done, then opens the region picker for a new recording. In v4.0.3 it ran a second stop instead. Whether a press during a stop should be dropped is the maintainer's call, so #15073 leaves this alone.Codex Medium reviewed the diagnosis and the fix. It agreed that
quattrofixes the race and found no problem with the guard. It suggested the wording of the code comment, which is now in the commit, and it confirmed the toggle change described above by reading the code. Its independence isn't guaranteed, because it can read this session.This now waits on the maintainer to review #15073. #11520 was this issue's earlier fix, and it conflicts with
quattronow.