[Bug]: macOS — takes end with SCStreamErrorDomain -3821 "Stream was stopped by the system" when the disk is low on free space

Aperta
  • Qualcosa non va?
#1,496 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
54/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend, desktop

Direzione di ricerca

Start with electron/recording/nativeMacCaptureStop.ts and electron/native/screencapturekit/Sources/OpenScreenScreenCaptureKitHelper/ScreenCaptureRecorder.swift, which the report identifies as passing the macOS stream error through to the user. Check how the app reads free space on the recordings volume and handles SCStreamErrorDomain code -3821; the report proposes a clearer message and a low-space warning, with stream recovery as an option. Done means the reported failure gives users useful guidance, and any warning or recovery behavior is covered by relevant tests.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Search existing issues
  • I have searched the existing issues
Describe the bug

TLDR: if you're low on space on your machine, make the error a bit more obvious regarding what's happening. 😄

On macOS 26, five takes in one 15-minute session ended early with:

Recording ended early (Error Domain=com.apple.ScreenCaptureKit.SCStreamErrorDomain Code=-3821 "Stream was stopped by the system" UserInfo={NSLocalizedDescription=Stream was stopped by the system}). The part recorded until then was saved.

Image

From the user's side this looks random: the stops came 1 s, 37 s, 95 s, 205 s and 289 s into a take. The unified log shows the cause. The data volume had less free space than macOS wants to keep (the CacheDelete purge goal in the log is ~15 GB on this 500 GB disk). While it is below that, the CacheDelete daemon (deleted) runs a purge every few minutes and asks replayd to free space at high urgency. replayd responds by calling stopAllStreamsWithError:, which ends every active ScreenCaptureKit stream, OpenScreen's included.

The sequence is the same for all five stops. Here is one of them:

14:25:03.797 deleted   Purge: goal 14817637171 freespace 9721704448
14:25:11.465 replayd   -[RPRecordingManager purge:urgency:]:263 cacheDeleteUrgencyHigh
14:25:11.465 replayd   -[RPClient handleMemoryWarningForCurrentActiveSession]:1085 We don't have a current active session.
14:25:11.465 replayd   -[RPClient stopAllStreamsWithError:]:1521
14:25:11.590 replayd   -[RPClient stopAllStreamsWithError:]_block_invoke:1532 Stopped stream=<private>
14:25:11.591 openscreen-screencapturekit-helper  -[SCStreamManager stream:didStopWithError:]:125 didStopWithError=Error Domain=com.apple.ScreenCaptureKit.SCStreamErrorDomain Code=-3821
Take started Stopped by system Into the take Free space at the purge
14:16:12 14:16:14 1 s 11.6 GB
14:16:33 14:18:08 95 s 10.7 GB
14:18:34 14:19:11 37 s 10.6 GB
14:21:46 14:25:11 205 s 9.7 GB
14:26:47 14:31:36 289 s 8.5 GB

The takes I stopped myself in the same session ended normally. replayd logged stopAllStreamsWithError: 298 times that day, so on a nearly full disk any take longer than a few minutes is likely to be cut.

Recording makes the problem worse as it goes. With the webcam at 1440p, one 289 s take wrote an 868 MB WebM plus a 380 MB MP4, so every take pushes free space further below the threshold.

The stop itself comes from macOS. replayd kills third-party streams even though it has no ReplayKit session of its own to purge, so OpenScreen can't prevent it. The app currently passes the raw NSError through: stream(_:didStopWithError:) in ScreenCaptureRecorder.swift emits capture-stopped-with-error, and nativeMacCaptureStop.ts wraps it in "Recording ended early (…)". This is unchanged on current main, so 2.2.x should behave the same as 2.1.2.

Expected behavior

OpenScreen can't stop macOS from doing this, but it could make the failure understandable and less costly:

  1. Name the likely cause. When a take ends with -3821 and the recordings volume is low on space, say so. For example: "macOS stopped the recording because the disk is almost full (8.5 GB free). macOS interrupts screen recordings while free space is low. Free up space and record again."
  2. Warn before recording. Show a warning in the HUD when the recordings volume is below ~15 GB free (or below whatever threshold deleted uses).
  3. Optionally, recover. On -3821, restart the stream and continue the same take instead of ending it. Each time, a new take on the same display (started by hand 20–80 s later) worked. Purges come in bursts, though, with another stopAllStreamsWithError: often 5–15 s after the first, so an automatic restart would need to wait or retry.
To Reproduce
  1. Reduce free space on the data volume to below ~15 GB.
  2. Start a screen recording with OpenScreen (display capture through Apple's picker; webcam, microphone and system audio were on).
  3. The take ends with the -3821 toast within a few minutes, at the next CacheDelete purge.

I matched this against the logs of an actual session. I didn't reproduce it by filling the disk on purpose.

To confirm the cause on an affected Mac:

/usr/bin/log show --last 1h --style compact --predicate '(process == "deleted" AND eventMessage CONTAINS "Purge: goal") OR (process == "replayd" AND eventMessage CONTAINS "stopAllStreamsWithError")'
OS

macOS

OS Version

macOS 26.0.1 (25A362)

Device Type

Desktop (Mac Studio, M4 Max)

Additional context
  • OpenScreen 2.1.2 (com.etiennelescot.openscreen)
  • The partial takes were saved correctly, with matching screen and webcam durations, so stopping and saving the take works. The only problems are the message and the interruption itself.
  • Related but different: #621, where the writer died and ScreenCaptureKit kept running. Here ScreenCaptureKit itself is stopped by the OS.
Lingua principale
TypeScript
Stelle
3.7k
Fork
231
Merge medio
19h 7m
PR unite (30g)
266

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di getopenscreen/openscreen

Tutte le issue di getopenscreen/openscreen

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.