Repository navigation
Screen capture flashes: asynchronous connecting state triggers repeated session restarts #784
Description
Activity
Screen and window capture can flash after asynchronous WGC startup: the core returns connecting, the shell treats that as a failed connection and retries, and each request retires/recreates the capture session. Live beta logs showed repeated screen:0 reconnects paired with missing-frame placeholders and texture eviction.
Preserve accepted pending screen/window requests across shell discovery refreshes and make duplicate lifecycle requests idempotent while pending or connected. A completed failure still permits retry; explicit disconnect/reconnect still creates a new session. Signal presence remains separate from session acceptance.
Addresses #784. Do not close it until installed acceptance with the streaming workload is complete.
Validation on b2c5985:
- Production Release native build and clean self-contained shell publish passed. Startup probe passed after a standard clean corrected stale WinUI resources.
- 24 focused native tests and 22 focused shell source-policy tests passed. The initial combined native filter selected zero cases and is not counted; verified individual suite filters ran the tests above.
- All hosted PR checks passed.
- Packaged production native capture: display 2560x1440 and application window 1422x1040, 240 samples over approximately 61 seconds, 480 repeated connect requests, no source content/membership disappearance. Window frame ingress advanced from 5 to 2190; the static display advanced from 1 to 2, so this does not establish moving-display continuity for that phase. Explicit disconnect removed both sources and reconnect restored both. Texture create/evict counts were consistent with the initial connection and intentional reconnect, not a restart storm.
- Packaged shell with both sources assigned: 240 samples over 60.6 seconds; no missing capture sources; display/window frame counters advanced from 967/610 to 4425/2600. Three initial connect requests (two racing requests for the display and one for the window), no repeating connect storm, and render deadline misses stayed zero during the measured interval.
- Package validation passed and an unpublished QA installer was built. Windows returned UAC cancellation before setup launched, so this is packaged validation, not installed acceptance. No external stream or meeting was started for these checks; physical display presentation and capture plus HEVC long-run acceptance remain unverified.
Test processes are closed. The three production preference files were restored with matching hashes and OAuth callback handlers restored to the existing installed beta. That installation and its camera registration remain unchanged. Raw logs and counter-only snapshots are preserved privately under capture-reconnect-784/artifacts.
- added a commit that references this issue
on Oct 4, 2026
Regression and root cause
Installed beta beta-2026-10-04-2be0494 flashes screen/window capture. Live logs on October 4, 2026, 12:03–12:05 EDT show repeated auto-connect requests and responses with match=connecting for screen:0, followed by repeated capture texture create/evict events and NO matching frame placeholder logs. No runtime change was made during capture.
Commit cddcab4 (#780/#517) moved WGC lifecycle creation to an asynchronous worker. connect() now returns while status is connecting. ShowInputRosterService.NativeCaptureSessionStarted accepts connecting only for NDI, not screen/window sources. StudioViewModel consequently sets the screen to Detected, releases its in-flight guard, and auto-connect retries on subsequent refreshes. CaptureSessionLifecycle::request treats every connect as a new revision; run retires the active session before creating its replacement. Repeated requests therefore restart or supersede capture initialization and remove frames between sessions.
Concrete live sequence: at 12:04:01.889, 12:04:02.103, 12:04:02.324 and 12:04:02.381 EDT, screen:0 auto-connect requests each returned connecting. The compositor repeatedly evicted/recreated capture:screen:0 and drew a placeholder when it disappeared. Window capture also exhibited repeated connecting retries.
Repair
Preserve an explicit pending lifecycle state through UI refreshes; an accepted asynchronous connection is not a failed start. Make repeated connect requests for an already pending/active live session idempotent, without preventing explicit disconnect/reconnect or bounded retry after a genuine failure. Avoid putting another ingest path in MediaCore or growing StudioViewModel; use focused lifecycle/policy types.
Acceptance
Meaningful regression tests must cover delayed asynchronous creation across repeated UI refresh/connect requests, proving one session creation, no retirement/revision invalidation during the pending interval, and continuous held-frame membership once running. Cover genuine failure/retry and explicit disconnect/reconnect. Build production Release and validate installed screen and window capture concurrently with a long-running HEVC stream; preserve full resolution/fps. Confirm no repeated connect storm, texture churn, placeholder flashing, or new capture-induced Program stalls.
Private logs/snapshot preserved locally in preserved-local-evidence/beta-2026-10-04/screen-flashing-*. This incident is distinct from Zoom receive freezes (#624) and does not invalidate the earlier operator-observed clean long HEVC run.