Agent: server-side throughput rates + killable-on-stop ffmpeg #183

2026-07-01T20:00:56-04:00

bvandeusen commented

2026-07-01 20:00:56 -04:00

Follow-up to PR #182, from live debugging of "work/min never populates" and "stopped never reached". CI-green on 713a11e (run 1843).

713a11e — server-side rate metrics + killable ffmpeg.
1. jobs/min + downloads/min are now computed in the backend (worker._rate_loop, EWMA on a fixed cadence) and reported ready-to-show. They were derived client-side from poll deltas with a dt<30s guard — but a backgrounded/unfocused browser tab throttles timers to ~1/min, so every delta blew past the guard and the rates blanked forever. Server-side rates are independent of poll rate. (Also explains the state-pill lag: a throttled tab repaints ~1/min.)
2. ffmpeg video sampling is now killable on Stop. A downloader stuck in a slow/reconnecting decode (observed 47s, 230s per video) couldn't see the stop signal until ffmpeg returned, so Stop detached still-running threads and work kept flowing. sample_frames_from_url now runs ffmpeg via Popen and polls a should_stop callback every 0.5s, terminating/killing the process at once on Stop or the per-video timeout; a stop-killed job is handed back (transient), not failed.

No client-side data storage or computation of authoritative values remains (audited): all counters/state live in the backend Worker; the browser only pulls + displays.

Deploy note

Agent runs :latest (main) → needs main + a re-pull on the desktop agent. No migrations; web/backend unaffected.

🤖 Generated with Claude Code

Follow-up to PR #182, from live debugging of "work/min never populates" and "stopped never reached". CI-green on `713a11e` (run 1843). - **`713a11e` — server-side rate metrics + killable ffmpeg.** 1. `jobs/min` + `downloads/min` are now computed in the backend (`worker._rate_loop`, EWMA on a fixed cadence) and reported ready-to-show. They were derived client-side from poll deltas with a `dt<30s` guard — but a backgrounded/unfocused browser tab throttles timers to ~1/min, so every delta blew past the guard and the rates blanked forever. Server-side rates are independent of poll rate. (Also explains the state-pill lag: a throttled tab repaints ~1/min.) 2. ffmpeg video sampling is now killable on Stop. A downloader stuck in a slow/reconnecting decode (observed 47s, 230s per video) couldn't see the stop signal until ffmpeg returned, so Stop detached still-running threads and work kept flowing. `sample_frames_from_url` now runs ffmpeg via `Popen` and polls a `should_stop` callback every 0.5s, terminating/killing the process at once on Stop or the per-video timeout; a stop-killed job is handed back (transient), not failed. No client-side data storage or computation of authoritative values remains (audited): all counters/state live in the backend `Worker`; the browser only pulls + displays. ## Deploy note Agent runs `:latest` (main) → needs `main` + a re-pull on the desktop agent. No migrations; web/backend unaffected. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

bvandeusen added 1 commit 2026-07-01 20:00:56 -04:00

fix(agent): server-side rate metrics + killable-on-stop ffmpeg

CI / lint (push) Successful in 2s

Details

CI / frontend-build (push) Successful in 19s

Details

CI / backend-lint-and-test (push) Successful in 25s

Details

CI / integration (push) Successful in 3m25s

Details

713a11e394

Two follow-ups from live debugging of "work/min never populates" and
"stopped never reached".

1) jobs/min + downloads/min are now computed in the BACKEND on a fixed
   cadence (_rate_loop, EWMA) and reported ready-to-show. The rates were
   derived client-side from poll deltas with a dt<30s guard — but a
   backgrounded/unfocused browser tab throttles its timers to ~1/min, so
   every delta exceeded 30s and the guard blanked the rates forever. A
   server-side rate is independent of how often the tab polls. Frontend just
   displays s.jobs_per_min / s.downloads_per_min. VERSION → .9.

2) ffmpeg video sampling is now killable on Stop. A downloader stuck in a
   slow/reconnecting decode (observed: 47s, 230s for one video) couldn't see
   the stop signal until ffmpeg returned, so Stop detached still-running
   threads and work kept flowing long after — "stopped" that wasn't really
   stopped. sample_frames_from_url now runs ffmpeg via Popen and polls a
   `should_stop` callback every 0.5s, terminating (then killing) the process
   at once on Stop or the per-video timeout. A stop-killed job is handed back
   (transient), not failed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

bvandeusen merged commit 489e6aaaee into main

2026-07-01 20:01:00 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bvandeusen/FabledCurator#183