Repository navigation
[Bug]: The video is not saving from the page, and this error appears. #327
Description
Search existing issues
- I have searched the existing issues
Describe the bug
Timed out waiting for native Windows capture to stop. The recording could not be saved openscreen
The video is not saving from the page, and this error appears.
Expected behavior
please help me
I searched all of Google.
To Reproduce
No response
Screenshots
No response
OS
None
OS Version
No response
Other OS
No response
Browser
None
Browser Version
No response
Other Browser
No response
Device Type
None
Other Device
No response
Additional context
No response
Activity
Raydy commentedon Aug 10, 2026
I have the same issue.
OS: Windows 10 / OpenScreen version: v1.9.3-rc.1
feat(wgc): report which GPU capture landed on, and let the tool test …
EtienneLescot commentedon Aug 10, 2026
There is a release candidate with a first attempt at this: https://github.com/getopenscreen/openscreen/releases/tag/v1.9.4-rc.2
Being straight about it: nobody has reproduced this on hardware we control, so it is not proven to fix your case. What the build does add is a way to answer the leading hypothesis without guesswork — it now reports which GPU the capture device landed on versus which one drives the display being captured, and a failed stop names the exact call each thread was inside.
If you hit it again on rc.2, the details and what to attach are in #252 (comment) — a couple of lines from the log settle more than a description can.
fix(wgc): make the GPU encode path opt-in until it earns the default
fix(wgc): make the GPU encode path opt-in until it earns the default
EtienneLescot commentedon Aug 11, 2026
Use
v1.9.4-rc.3rather than rc.2: https://github.com/getopenscreen/openscreen/releases/tag/v1.9.4-rc.3rc.2 switched Windows recording onto a GPU encode path by default, and on @Afton-programmer's machine that replaced this timeout with a different failure (#336). rc.3 turns it back off, so recording behaves as it did in 1.9.3 while the diagnostics stay in.
That means rc.3 is not expected to fix the timeout reported here — it is expected not to make anything worse, and to say more when it happens. If you still hit it, the details of what to attach are in #252 (comment); two lines from the log settle more than a description can.
EtienneLescot commentedon Aug 11, 2026
One question, and it is a small one — the answer would narrow this down more than anything else we can do right now.
Which graphics card does the affected machine have? If it is a laptop with both an integrated and a discrete GPU, both names, and which one Windows says is driving the display.
The fastest way to get it:
PowerShell
Or: right-click the desktop → Display settings → Advanced display → the adapter name is at the top. Task Manager → Performance also lists every GPU in the machine.
Why it matters
Every reporter who has stated their OS is on Windows 10, and both reporters who have stated their hardware have a discrete GPU. Neither machine we can test on matches on either count — ours are Windows 11 with integrated graphics only — so the two possible causes are perfectly tangled in the data we have, and we cannot tell them apart.
Your answer breaks the tie. If your machine has no discrete GPU, one of the two hypotheses dies immediately and we stop chasing it. If it does, the remaining question is a specific one we can rent hardware to test.
No logs, no reinstall, no reproduction attempt needed — just the adapter name.
fix(recording): write fragmented MP4 so a killed helper keeps its file
fix(recording): write fragmented MP4 so a killed helper keeps its file
fix(recording): open the recording a failed stop left playable
fix(recording): open the recording a failed stop left playable
Raydy commentedon Aug 18, 2026
Name DriverVersion
GameViewer Virtual Display Adapter 15.6.5.199
NVIDIA GeForce GTX 1080 32.0.15.6094
Raydy commentedon Aug 18, 2026
Name DriverVersion
GameViewer Virtual Display Adapter 15.6.5.199
NVIDIA GeForce GTX 1080 32.0.15.6094
EtienneLescot commentedon Aug 20, 2026
#363 (shipped in 1.9.5) covers the data-loss half of this: a take left behind by a failed stop is now opened and kept instead of being discarded with an error. Could you confirm on 1.9.6 that the recording survives?
The stop hang itself is untouched and tracked in #252 / #292.
EtienneLescot commentedon Sep 10, 2026
Duplicate of #252.
Two separate things were reported here, and they are in different states:
@Raydy, your adapter list did answer the question I asked, and the answer turned out to be that the virtual display is not the cause. A machine without one fails identically. That was worth knowing and it took your reply to get there.
Closing so there is one thread rather than three. The request to test v1.11.0 is in #252.