Recording status loses encoder job after stop timeout; incomplete artifact looks ready

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

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

Closed bug report

John Lauer · 2mo ago ·closed by John Lauer

Environment: Hydrogen 1.0.315 (build 6faf5d05ebf27f536cf6ec61ea43026cfefcf717), Adom Bridge 2.1.88, Windows AdomLapper with Linux/WSL2 tooling. Pup installed/running 2.0.452. Observed during TMF8829 Depth Lab stage sourcing.

pup_record_stop for recording rec-8287 exceeded the caller's 50 second timeout. A subsequent pup_record_status reported recording:false,current:null, while the matching ffmpeg encoder still existed (PID 15800, matching recording output and concat input, approximately 579 MB RAM). An early pull returned exactly 1,048,576 bytes with a WebM header but no duration. Once the encoder exited, the same output was 2,987,112 bytes, 94.44 seconds, and decoded completely. We preserved the partial and recovered the completed file; no process was killed.

Please expose capture and encoding as separate states, retain recording/job ID after capture stops, and return a polling hint plus artifactReady:false while encoding. Stop retries should retrieve the existing job, not create or restart encoding. A completed state should include final byte count, duration, path and encoder error. A non-recording status must not imply a finalized file. Test with deliberately slow VP9 encoding and a caller timeout. This report does not establish a capture-duration-cap bug.

Evidence: the attached process snapshot proves encoding was still active; final file SHA256 c8f5989cd6e48aed919721140640a854b01c7908bfefd23def5749272b07ef49.

C81-encoder-processes.json

1 Reply

John Lauer · 1mo ago

Addressed in pup 2.0.649 (insiders). On the screencast fallback the encode is a job: pup_record_stop stops the capture, starts the mux in the background, waits up to 20 s, and if the encoder is still running answers ok with artifactReady:false, phase:'encoding', the recordingId and statusVerb pup_record_status. pup_record_status reports jobs[] with phase and artifactReady; a later pup_record_stop for the same window returns the finished file with its final bytes and never starts a second encode; an encoder error is reported as mux_failed. The default recorder is ab's native one (H.264 MP4, returned synchronously by ab), where this did not apply. Exercised by code review only tonight: no box in reach encodes slowly enough to outlive the 20 s wait; reopen with a status dump if a slow VP9 encode still vanishes.

John Lauer closed this · 1mo ago