You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Instant mode: start sound plays seconds before recording actually starts. Opening of most takes silently lost (0.6.1 GPUI) #3035
Since 0.6.1 auto-installed on 21 Oct, Cap has been losing the first 2 to 10 seconds of my recordings while telling me it's recording.
I record personal videos for prospects, one take each, opening with their name. Across two sessions, 15 of 18 takes lost that opening. That's the one line that makes the video personal. I've had to re-record, splice and push back sends twice in one week, and lost most of two days of production. A screen recorder that drops what you say after its own start sound is failing at the one thing it's for.
The cause is in your code. In apps/desktop-gpui/src/recording.rs, start_internal awaits prepare_instant_upload (create video on cap.so) before starting recording. The cue plays on the countdown regardless. When earlier takes are still uploading, that request takes seconds, and the user is already talking.
From cap-gpui.log, cue to actual start, 23 Oct:
takes with nothing uploading: 0.01, 0.10, 0.15, 0.17 s
takes after uploads queued: 2.30, 4.14, 3.84, 3.39, 4.92, 7.20, 3.03, 9.91 s
21 Oct: up to 16.4 s, once 102 s
Same night, 7 of 9 uploads stuck at "processing" with segment timeouts.
The fix is simple: never play the start cue until capture is live. Create the video in the background, or start capturing and attach the upload later. Instant mode is your headline feature, and right now it can't be trusted for a single take.
Activity
linear commentedon Oct 24, 2026
CAP-895
fix(desktop-gpui): hold the start cue until capture is ready