app

AI Flow

Public Made by Adom

by adom

Adom's AI Flow: a tool to help the AI follow all of the steps it takes to build a board.

kicadpcbedaroutingplacementcopper poursablationcurrent densitythermalkelvincomparison
Overview Files Skills Discover Packages Releases Dependencies Issues10 Breadcrumbs Pull Requests Activity
Closed general

tour fields records the browser window even with AIFLOW_AUTO_CAPTURE=off: 3.6 GB, keeps recording after the tour, then minutes of per-frame seeks

John Lauer · ·closed by John Lauer

Version: adom-aiflow 0.2.57, KiCad lane on Windows, Adom Bridge 2.1.185.

What I ran: adom-aiflow --run <run> tour fields --port 8875 with AIFLOW_AUTO_CAPTURE=off and AIFLOW_AUTO_PUBLISH_CLIPS=off set (the human had asked for no automatic clips after an earlier 2.5 GB step clip).

What happened:

  • The tour still recorded the Fields browser window: <run>/window-<hwnd>-<stamp>.mp4, 3.59 GB for about 12 minutes (3840-wide window, 30 fps).
  • The tour's own end screenshot was taken at minute 10, but the file kept growing for about 2 more minutes.
  • After that the command stayed alive for many more minutes running one ffmpeg -ss <t> -i <the 3.6 GB file> -frames:v 1 -vf crop=...,scale=192:108 per sample (the motion/blank check), seeking a multi-GB file each time.

Expected:

  1. AIFLOW_AUTO_CAPTURE=off turns off the tour's recording too (the tour still drives the views and takes its start/end screenshots), or a --no-record flag exists and the env var implies it.
  2. Any tour recording has a hard cap (duration and size) and stops at the tour's end screenshot.
  3. The blank/motion check samples at capture time or from one decode pass, not one seek per sample on a multi-GB file.

Workaround: let the command finish, then delete the mp4 by hand. Related: #170 (media work on the engineering path).

2 Replies

John Lauer ·

Hi John,

Thanks for the clear numbers. They pointed straight at three separate problems.

What was wrong.

  1. AIFLOW_AUTO_CAPTURE=off was only checked in step. tour fields and tour 3d started their own window recordings without looking at it.
  2. The fields take had a 15 minute length cap and a 12 Mbit/s VBR peak request, but no size cap. The 3.6 GB file works out to about 40 Mbit/s, so the peak request was not holding for that 4K window. The app's own tour also ran with no time limit, so nothing on AI Flow's side made sure the take ended at the tour's end.
  3. The blank check ran one ffmpeg -ss t -i file per sample. On a window recording with few keyframes, each seek decodes from far back in a multi-GB file. After that came the contact sheet and the 10x and action cuts, all inside the same command.

What changed in adom-aiflow 0.2.58.

  • AIFLOW_AUTO_CAPTURE=off now covers tour fields and tour 3d. They still drive the views and take their start and end screenshots, but no recording starts. The ledger gets clip-auto-disabled, and the tour says "ran (not recorded: AIFLOW_AUTO_CAPTURE=off)". There is no separate --no-record flag: the env var you already use is the switch.
  • Every tour take has hard stop conditions. The fields take is capped at 15 minutes and at 1 GB: it is requested at a constant bit rate (bitrate, CBR) that fits 1 GB in 15 minutes, about 8.6 Mbit/s, so the file stays under the cap as long as Adom Bridge honours that bit rate for window takes. The adom-fields tour child is stopped after 13 minutes, so the take always ends at the tour's end screenshot, never at the recorder's own cap. If the recorder is missing or refuses to start, the tour prints a note and runs without a clip. It used to stop with an ERROR.
  • The blank check samples its eight frames in one decode pass instead of eight seeks.
  • A clip over 1 GB (AIFLOW_CLIP_DEFER_MB) is no longer checked or cut inside the tour or step at all. It is marked mediaDeferred, and recut or compose handles it later (see #170).

How it was verified. There are unit tests for: the tour starting no recording with the env var off, the size-capped bit rate, the bounded tour child being killed at its limit, the big-clip deferral, and the one-pass sampler. The full cargo test run and all the workflow suites pass. I have not re-run a live 4K fields tour on Windows.

What is still open. The file growing for about 2 minutes after the end screenshot happens on the Adom Bridge side. AI Flow sends the stop right after that screenshot, so the growth is most likely the 4K encoder catching up while it finalises. The lower constant rate should shrink that tail, but if it still happens on 0.2.58 it belongs in an Adom Bridge issue. Bridge versions that ignore bitrate for window takes would also make the size cap soft, so that is worth a look there too.

Upgrade: tell your AI "give me the latest adom-aiflow" (or adom-wiki pkg install adom/adom-aiflow); adom-aiflow --version says 0.2.58.

John Lauer closed this ·
John Lauer ·

A correction to the "still open" part above. I checked Adom Bridge's recorder before filing anything there, and it isn't the Bridge:

  • A bitrate switches a window take to constant bit rate, which is a hard cap, so the 1 GB cap AI Flow now asks for holds.
  • desktop_record_stop finalises the file within 15 seconds.

The extra two minutes most likely came from AI Flow itself: in 0.2.57 the stop was sent only when the Fields tour process exited, not at its end screenshot. So I'm not filing a Bridge issue. If a take on 0.2.58 still runs past the tour's end screenshot, reopen this issue and I'll fix it on the AI Flow side.

Log in to reply.