Hold queue on startup until Start is clicked (env var to auto-start) #11

New Issue

2026-06-21T17:26:25Z

Kessinen commented

2026-06-21 17:26:25 +00:00

Today the watcher begins encoding immediately on startup if input/ already has files. Change the default so the daemon starts 'held': it scans and shows the queue but does not begin encoding until the user clicks Start in the UI. An env var (e.g. AV1DAE_AUTOSTART=1, truthy) restores the current start-ASAP behavior.

NOTE: this flips the current default behavior (auto-start -> held).

Design:

A global processing gate (running vs held) on the watcher/control. While held, scanAndProcess still tracks the queue (so /status shows what is waiting) but does not hand files to processFn.
UI: Start / Hold control on the dashboard; status shows 'Held - N files waiting' vs running.
API: POST /api/start and /api/hold (or a single toggle); /status exposes the gate state.
Default held; env var AV1DAE_AUTOSTART truthy -> start running immediately. (Env var per request; a -autostart flag or a config/settings field are equivalent alternatives.)

Distinct from #10 (pause an in-flight ffmpeg via SIGSTOP) - this gates whether the queue is processed at all. They compose: 'running' with the current encode paused, or 'held' with nothing running.

Behavior decision: if an encode is in progress when the user clicks Hold, recommend hold = 'do not start the next file' and let the current one finish (pausing the active encode is #10's job).

Mutation -> shares the auth consideration in #2 (deferred on the isolated network).

Today the watcher begins encoding immediately on startup if input/ already has files. Change the default so the daemon starts 'held': it scans and shows the queue but does not begin encoding until the user clicks Start in the UI. An env var (e.g. AV1DAE_AUTOSTART=1, truthy) restores the current start-ASAP behavior. NOTE: this flips the current default behavior (auto-start -> held). Design: - A global processing gate (running vs held) on the watcher/control. While held, scanAndProcess still tracks the queue (so /status shows what is waiting) but does not hand files to processFn. - UI: Start / Hold control on the dashboard; status shows 'Held - N files waiting' vs running. - API: POST /api/start and /api/hold (or a single toggle); /status exposes the gate state. - Default held; env var AV1DAE_AUTOSTART truthy -> start running immediately. (Env var per request; a -autostart flag or a config/settings field are equivalent alternatives.) Distinct from #10 (pause an in-flight ffmpeg via SIGSTOP) - this gates whether the queue is processed at all. They compose: 'running' with the current encode paused, or 'held' with nothing running. Behavior decision: if an encode is in progress when the user clicks Hold, recommend hold = 'do not start the next file' and let the current one finish (pausing the active encode is #10's job). Mutation -> shares the auth consideration in #2 (deferred on the isolated network).

Kessinen added the enhancement ui labels 2026-06-21 17:26:25 +00:00

Kessinen closed this issue

2026-06-21 17:38:32 +00:00

Kessinen referenced this issue from a commit

2026-06-21 17:38:33 +00:00

add: processing controls — start/hold, pause/resume, retry

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Kessinen/av1dae#11