Native recorder: stop hangs ~50 s and returns ok:false; MP4 left without moov (unrecoverable)

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

Closed general

John Lauer · 15d ago ·closed by John Lauer

What happened (Windows Hydrogen v1.0.572, 2026-10-07, on a 2560x1600 laptop display with an NVIDIA GPU)

POST /recording/native/start {"source":"self","codec":"h264","maxSeconds":400,"reason":"..."} started fine (engine: wgc, source: window:Hydrogen v1.0.572 …). About 196 s later POST /recording/native/stop hung for ~50 s and returned {"ok": false} with no error text.

The output file ~/project/recordings/recording-1791404577.mp4 is unusable:

boxes on disk: ftyp 24 B, uuid 39 B, mdat declared 520,339,319 B, but the file is only 175,374,336 B and stopped growing;
no moov atom, so ffprobe says "moov atom not found" and the take can't be recovered (no frame timing).

GET /recording/native/status afterwards reports recording: false, with lastOutput still pointing at the previous (good) take.

An earlier take the same afternoon with the same settings (200 s, 59.4 fps, 482 MB) finished fine. It looks like the encoder's writes into the WSL path (\\wsl$\…\recordings\) fell behind at ~60 fps and full bitrate, and stop gave up while flushing.

After this, Adom Bridge's recorder on the same PC also failed to start ("encoder init timed out" for h265, "Request timed out" for h264) and once failed mid-take with WriteSample failed … sample allocator is currently empty (0xC00D4A3E), as if a hardware encoder session had been left held. See the companion issue on adom/adom-bridge.

Asks

When stop can't finalise, say why (error text), keep the take registered, and expose a way to finish or collect it, as Adom Bridge's recorder does (state: finalising, then poll).
Write fragmented MP4 (or keep a recoverable index) so a failed stop still leaves a playable file.
Offer fps / bitrate on /recording/native/start; there's no way to lower the data rate today.
Consider recording to a Windows-local temp file and moving it into the workspace after finalise, instead of encoding straight through \\wsl$.
Release the encoder session on any failure path.

1 Reply

John Lauer · 12d ago

Fixed. Hydrogen's /recording/native/* now records through Adom Bridge's recorder (1.0.593), with two follow-ups in 1.0.595 (insiders).

Same take as this issue, run on ConfRoomROG: Hydrogen's own window, H.264, 60 fps, 217 s.

engine: ab, never 0 frames, encoder backlog 0.
The file is complete and playable: fragmented MP4 with moov and moof, 245 MB, 13,064 frames over 217.7 s (a constant 60 fps). Nothing was lost.
The stop took 69 s, and returned the file in the project's recordings/.

What changed:

The engine: engine:auto records through ab: desktop_record_window_start for self and window:..., desktop_record_start for a monitor. That gives H.264/H.265 on the GPU, system audio on screen sources, fps and bitrate, and fragmented MP4.
A take is never dropped: when ab answers state: finalising, Hydrogen polls until the file is done, then collects it.
Fallbacks: WGC when ab can't start or delivers 0 frames; gdigrab for screen:all, mkv and virtual displays. engine:'ab' forces ab and says why it couldn't.
Copy deadline (1.0.595): the copy into the workspace had a flat 60 s deadline, which a take over about 300 MB (roughly 5 minutes) would have missed. It now scales with the file: 60 s plus 1 s per 2 MB, capped at 30 minutes.
Frame count (1.0.595): status and stop report encodedFrames, the file's frames. The captured count was window changes: 282 for an idle window, which read as 1.3 fps.

On the asks: (1) stop reports why and keeps the take with ab; (2) fragmented MP4; (3) fps and bitrate; (4) the file was already recorded to a Windows temp file and moved after finalise; (5) ab owns the encoder session.

Still slow: most of the 69 s stop is the 245 MB copy across WSL's /mnt/c bridge.