Build1 distinct publisher3 min readUpdated
An unattended video pipeline on macOS launchd stopped dying overnight after a startup wait went from 180s to 600s and a download timeout from 90s to 240s. The logic never changed.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A developer running an unattended video pipeline on a Mac reported that raising two timeout values took the job from failing two or three mornings a week to running itself [4][5][6]. That is the whole fix worth reading about, because it says the failure was never in the code path: it was in an assumption about how fast a machine wakes up.
The pipeline chains ComfyUI, FFmpeg and the Freesound API to produce long-form ASMR videos, and it is scheduled through macOS launchd to fire at a fixed time each day [1][2]. According to the author's write-up on dev.to, the recurring break was a cold start: you boot the Mac and ComfyUI simply is not running yet [3]. The script waited 180 seconds for it to come up, which is a reasonable number if you are watching a terminal and a bad one if the model backend is doing several minutes of MPS inference on a machine that just resumed [4][13]. The wait went to 600 seconds. The Freesound download timeout went from 90 seconds to 240 [5]. In multiples that is roughly 3.3x and 2.7x the original budgets [7], and it converted a job failing something like 29 to 43 percent of mornings into one the author checks rather than nurses [8][6].
The rest of the design is what makes generous timeouts survivable. launchd fires two slots, 07:00 and 14:00; if the Mac slept through the first, the second is the recovery run [10]. An idempotency guard at the top of the script looks for any directory matching today's date under the output root and, if one exists, logs "already stocked" and exits 0 [9]. That guard is only safe because the output directory lands atomically at the end of a run with the video, thumbnail, youtube.md and still image already in place, so a half-finished run does not leave a decoy directory that suppresses the retry [11]. Longer timeouts plus a retry slot plus an exit-0 guard is a coherent set. Any one of them alone is a worse system.
Observability is one append to coverage.csv per run, with the columns date, theme, duration, sound count, size and status; a successful YouTube upload rewrites the trailing status from OK to OK+uploaded with sed [12]. One line, checked once a morning. The same idempotent structure gives backfill for free: a --date flag fills a missed day, and --still skips launching ComfyUI entirely and remixes audio over an existing image [14].
Two things to watch. First, 600 and 240 are not measurements, they are envelopes around an observed worst case, and worst cases move when a model, a disk or a network path changes; the CSV is the only instrument that will report the drift [12]. Second, the write-up does not describe a lock or overlap guard for a 07:00 run still executing when the 14:00 slot fires [18], and a 600-second wait makes that window wider than it was at 180.
The economic case is separate and thinner: the author's stated motivation was that 30 hand-made videos a month is 60 to 90 hours of work, an attempt that collapsed in two weeks alongside a side job [15], and that keeping ComfyUI and FFmpeg local means no vendor can reprice the pipeline out of existence [16][17]. That claim is untested here. The timeout numbers are not.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The ComfyUI startup wait was raised from 180 seconds to 600 seconds.
The Freesound download timeout was raised from 90 seconds to 240 seconds.
The pipeline is scheduled with macOS launchd so it fires at a fixed time every day.
The author describes the failure mode as the "cold start" problem: you boot the Mac and ComfyUI simply isn't running.
Before the two timeout changes, mornings failed 2 to 3 days a week.
launchd fires two slots, 07:00 and 14:00; if the Mac sleeps partway through, the 14:00 slot handles recovery, and the idempotency check prevents double generation.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single self-reported build log with code, no external verification
The technical mechanics are unusually well shown for a personal post — literal shell snippets for the idempotency guard and coverage.csv, plus an ordered 12-step execution diagram that independently corroborates the 600s wait and 240s Freesound timeout. But every quantitative reliability claim (2-3 failed mornings a week, the improvement afterwards) is one author's recollection with no logs, run history, measurement window or third-party replication, and the piece even contradicts itself on concurrency handling.
One operator, one machine, self-disclosed
Adoption evidence is limited to the author's own unattended runs on a single Mac plus occasional use of the --still shortcut. No other users, forks, downloads, repository, or organisational deployment is disclosed anywhere in the supplied source, so this is a personal-workflow data point rather than diffusion.
Modestly overstated: real technique, absolute framing
The core assertion — that raising two timeouts rather than rewriting logic stopped the nightly failures — is plausible and well specified, and the post is refreshingly small in ambition (a personal pipeline, not a product). Overstatement is concentrated in absolutes: 'self-healing', 'a price hike or the death of a free tier can't stop the automation' despite listed Freesound and YouTube API dependencies, and 'no double generation' when the prose's own guard cannot cover an in-flight overlapping run. The improvement is also unquantified after the change, so the framing outruns the published measurement.
Self-published series with personal monetisation motive
The author writes on a personal dev.to account as the second instalment of a series about their own content-automation setup, framed around losing a job, income going to zero and the need 'to sustain monthly revenue' from unattended YouTube output. That creates a clear incentive to present the pipeline as working and self-healing, and to promote the series. There is no disclosed vendor sponsorship, paid placement or employer interest in any named tool, which caps the score below the high band.
Mechanism clear, outcomes weakly evidenced
Confidence is moderate-low: the cluster has one publisher and one item, so nothing is independently corroborated, and the key outcome metric is anecdotal. It is not lower because the published code and step diagram make the configuration change itself verifiable on its face and internally consistent, and because the identified weaknesses (missing post-change data, prose/diagram mismatch, residual API dependencies) are visible in the source rather than speculative.
build
Every viewer hits your HLS key endpoint in the same second, and almost nobody tests it1 distinct publisher
build
FFmpeg.wasm ships, but budget for a watchdog: one in ten heavy jobs deadlocked in silence1 distinct publisher
build
The streaming edit is a software layer: proxies, stubs and an ffmpeg hook on storage you own1 distinct publisher
build
launchd Tells You Nothing When a Job Dies, So Your Revenue Reports It Instead1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 15, 2026