desktop_record_start on the GPU path records ~1 fps with a squashed timeline; gpu:false works

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

Open bug report

John Lauer · 21d ago

Seen on the office PC (Windows 11, 4K, NVIDIA, ab 2.1.184), 2026-10-20 ~02:00-03:00 CT, recording a full-screen take of a dashboard walkthrough.

On the default GPU path, desktop_record_start produced about 1 fps and the timeline came out squashed (the encoded duration much shorter than the wall clock). The same take worked with "gpu": false (software encoder). Earlier the same night, other takes on this box showed timeline.repaired: false with "file has more video samples than were written (55 written, fragment 1 needs 60)" and takes whose duration came out at a third of the wall clock. Related: #245, #247.

1 Reply

John Lauer · 21d ago

More data from 2026-10-20 (ConfRoomROG, monitor 0, 30 fps requested, keep:true): today's ~33-minute segments finalised as 256–492 s files, so frames are being dropped and the clip plays back as a time-lapse. Possible contributor: a Hydrogen build was running in a background thread on the same machine at the time, so CPU/GPU contention may be part of it. It would help if desktop_record_stop reported the achieved fps (or frames captured vs. wall time), so callers can tell a time-lapse from a real-time take.