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: clip stop waits forever on a recording ab no longer lists; 4K static capture reaches 4 GB in 10 min

John Lauer · ·closed by John Lauer

adom-aiflow 0.2.18, run on a KiCad board, tour fields --port 8875 filming the Adom Fields pup window (3840x2064) on a Windows desktop through Adom Bridge 2.1.184.

What happened:

  • The tour ran from 15:39:46 to 15:50:10 UTC: it wrote its fields-start and fields-end screenshots and the fields-emc event.
  • The clip (recordingId rec-539427fbaee946f7a3b2fbf65079b8ca) was 624 s of H.264 at 55 Mbit/s, 4.29 GB, although the window was mostly static. The file stopped growing at 15:50:10.
  • After that the tour process sat for 36+ minutes in sleep, single-threaded, no CPU, no network socket open, never ending the step.
  • desktop_record_status then listed no active recording, and desktop_record_stop with that id answered 'No recording with id ...'. Other finalised recordings in the same registry show finaliseMs of 621458 and 1139148 (10 and 19 minutes).

Expected:

  • The clip stop/pull should time out and either fail the step with a clear ERROR, or mark the clip pullFailed (as the other steps do), when ab no longer knows the recording or the finalise runs past a limit.
  • A window clip should have a hard size or duration cap and a bitrate that suits a near-static UI window; 55 Mbit/s at 4K made a 4 GB file.

Worked around by killing the tour by pid, cutting a 62 s 10x clip from the file, deleting the 4.29 GB original, and re-running the tour with an external size and time watchdog.

1 Reply

John Lauer ·

Fixed in adom-aiflow 0.2.19.

  • Likely cause of "No recording with id": aiflow's own first stop had probably already collected the take. The unbounded waits were the adom-bridge calls themselves: no process timeout, and pull_file could run 3600 s times 3 attempts. The old stop also never handled a finalising answer, and could pull a file that wasn't finished.
  • The stop is now bounded.
    • A finalising take is polled with desktop_record_status every 10 s for up to 5 minutes (AIFLOW_CLIP_FINALISE_SECONDS), then collected.
    • A take Adom Bridge no longer knows, or one that failed to finalise, returns at once.
    • Stop and status calls have a 120 s limit, and the pull has an overall limit.
    • A clip with no file is marked pullFailed with the reason, instead of the step hanging. A take still finalising gets stopPending, and recut, finish and deliver collect it later.
  • Size: every window recording aiflow starts now passes maxBitrate 12 Mbit/s (AIFLOW_CLIP_MAX_BITRATE overrides), about 90 MB a minute instead of 55 Mbit/s. The fields walkthrough's take stops itself after 15 minutes.
  • Not yet verified live: that this Adom Bridge version honours maxBitrate on window recordings. The next tour fields will show it; please post the file size if it is still large.

Upgrade: adom-wiki pkg install adom/adom-aiflow, then adom-aiflow --version says 0.2.19.

John Lauer closed this ·

Log in to reply.