Monitor recording stops taking frames mid-take (frozen or black file) while fresh recordings work

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 1mo ago ·closed by John Lauer

On arav-rog (ab 2.1.170, NVIDIA H.264 encoder, monitor 1 = 2560x1440 external display), a desktop_record_start monitor recording sometimes stops taking new frames for the rest of the take while the screen keeps changing. The file grows and has the right duration, but holds one frame (or solid black) from some point on. A fresh desktop_record_start started during the bad take records live content normally.

Seen 2026-10-06/07 while recording a long Hydrogen + Fusion demo:

A 5-minute take froze on its first seconds (a wiki 404 page) and held that frame to the end, while 2-second recordings made every minute during it showed the screen changing (Hydrogen pages, then the Fusion library editor).
An 83-second take came back solid black, again while short recordings around it were live.
In an earlier 51-minute take, the recording held one frame from minute 10 to the end.

What would have saved hours:

desktop_record_status already reports capturedFrames and captureFps. When capture stops delivering frames while the encoder keeps writing, flag it in the status and the stop reply (stalled: true, lastFrameAt), and ideally re-create the capture item automatically.
Say it in the stop reply's _hint when a take's captured frames stopped early, so the caller knows the file is bad without decoding it.

Workaround that worked: record in short clips (10 to 15 s, or 5-minute segments) and compare first, middle and last frames of each before moving on.

1 Reply

John Lauer · 1mo ago

Shipped in 2.1.171 (insiders now): asks 1 and 2.

desktop_record_status and desktop_record_stop now carry:

lastFrameAgoMs: time since Windows last delivered a new frame.
captureItemClosed: the capture source raised Closed (display change, window closed, graphics reset). After that nothing new can arrive.
captureQuiet: a plain sentence when either looks wrong. The stop _hint becomes "The MP4 is finalized, BUT: ..." so the caller knows without decoding the file.

Windows only delivers a frame when the picture changes, so a still screen is also quiet. The note says that rather than guessing. In a monitor take the recording ornament animates on that monitor, so 15 s with no frame there means a real stall.

Checked on arav-rog (2.1.171):

A still Explorer window take: status read No new frame from Windows for 15s ... at 15.2 s, and the stop hint said the same.
Monitor takes kept lastFrameAgoMs under 1 s, with no false warning.

Not done: automatic re-creation of the capture item mid-take. The cause of the stall on that box is still unknown (the Closed event is now logged, which should tell us next time), and re-creating the capture blindly could mask a real fault. Short clips remain the safe pattern for long demos.

John Lauer closed this · 1mo ago