app

Adom Hydrogen

Public Made by Adom

by adom

The whole Adom experience as one signed native app: your editor, your AI agent, and the full electronics design toolchain, running locally on your own machine.

Overview Files Skills Discover Packages Releases Dependencies Issues20 Breadcrumbs Pull Requests Activity
Open general

Native recorder stuck in 'stopping' after the bridge finalised the take; every new start refused

John Lauer · 2d ago

What happened

A native window recording (POST /recording/native/start {"source": "window:Hydrogen ..."}, Hydrogen v1.0.659, AB 2.1.184, ConfRoomROG) chose the ab engine, ran 173 s at about 15 fps, and then a POST /recording/native/stop timed out on the caller's side (60 s). From then on:

  • GET /recording/native/status answers recording: true, state: "finalised", lastOutput: null, with seconds frozen at 173.2.
  • Every further POST /recording/native/stop answers ok: false, state: "stopping", "a stop is already finishing this take ... poll status until recording:false".
  • POST /recording/native/start (any source and engine) is refused: "a recording is already in progress (engine: ab): stop it first".
  • Adom Bridge's own desktop_record_status shows that take (rec-cb7ae38bdcaf4d9d9d890be598079d25, window-4000954-20261020-175114.mp4, 109 MB) as running: false, state: finalised. So the bridge finished; Hydrogen never left its "stopping" state (the move into recordings/ never happened or never reported back).

There is no reset, abort or cancel endpoint, so the native recorder stays unusable until Hydrogen restarts.

Asks

  1. When the bridge reports the take finalised, finish Hydrogen's state too (move the file, set lastOutput, recording: false), or time the "stopping" state out with an error.
  2. A POST /recording/native/reset (reason-gated) that clears a wedged state without restarting Hydrogen.
  3. The window source falling back to the ab engine at 15 fps deserves a hint at start: the caller asked for a window, the recommended engine was wgc.

2 Replies

John Lauer · 2d ago

Another case, 2026-10-20 on ConfRoomROG (Hydrogen 1.0.659), with a second effect: a stuck 'stopping' take blocks the updater.

  • Take rec-cb7ae38bdcaf4d9d9d890be598079d25 (window capture, maxSeconds 420) started 12:51 CT. At 14:05 CT /recording/native/status still said recording:true at 4,596 s, with remainingSeconds near 0 and bytes frozen at 108,725,778.
  • At 14:20 CT POST /recording/native/stop returned {"ok":false,"state":"stopping","error":"a stop is already finishing this take ..."}. bytes has not changed since.
  • Earlier, at 19:00 UTC, the container was OOM-killed (an ffmpeg using 19 GB). The take was probably orphaned then, as in #126.
  • New effect: POST /updater/install refuses with deferred and lists "native recording running (window:Hydrogen v1.0, 4596 s)" under busy. So a 1.0.660 update can't be applied without force:true, which would also cut off any running AI turns. The wedged take holds the updater hostage indefinitely.

Expected: a take past its maxSeconds whose file stopped growing should be finalized or abandoned automatically, and shouldn't count as "busy" for the updater.

John Lauer · 2d ago

That one was mine, introduced in 1.0.659, and it is fixed in 9d92442d (next build, 1.0.661).

Why it wedged. 1.0.659 added a "one stop at a time" lock, so a second stop during a long finalise would not start another collect. But the collect (ab finalising, then the copy into recordings/) ran inside the HTTP request, and the lock was released at the end of that request. When your caller timed out at 60 s, the request was dropped mid-collect, the release line never ran, and the recorder said "stopping" forever: every start was refused, and the take counted as busy for the updater.

Fixed, covering your three asks and the updater:

  1. The finish runs in its own background task with a guard that always releases the lock, so a caller that gives up can't cut it off. The take is still collected, lastOutput is set, and status goes to recording:false. Status also finishes, on its own, a take that Adom Bridge already finalised, or one whose file stopped growing well past its time limit (your case, at 4,596 s with maxSeconds 420).
  2. POST /recording/native/reset {reason} lets go of a wedged take without restarting Hydrogen. It deletes nothing: the bytes stay in abFile.
  3. Starting a window recording through ab now carries a hint: a window is captured as it repaints (an idle window gives about 15 fps), and engine:"wgc" gives a fixed rate.
  4. The updater: a take that is being stopped, or more than 2 minutes past its own time limit, no longer counts as running work, so it can't hold an install hostage.

ConfRoomROG right now: that box is still on 1.0.659, so its wedged take clears only on a Hydrogen restart (it then re-adopts the take, and a stop collects it). Or apply the update with force:true once nothing else is running there.

Gate entry recording-stop-caller-gone: a stop whose caller gives up after 3 s still ends with the file in recordings/ and recording:false, a new start works, and reset releases a take. I will close this after the build passes it.

Log in to reply.