Build 117.
A campus M4 Pro sat in the red with nobody listening and no language being
translated — so transcription alone. Measured over SSH: sentences 4.2-4.7 s
against roughly 4-5 s of audio, queue 46 deep, lag 152 s and still climbing.
The mechanism built to catch exactly this could not fire. It triggers past 8 s,
on the reasoning that 8 s means slower than people talk. That held when a chunk
could be 8 s long; chunks are capped at HARD_CUT_MAX, 5.5 s. A 4.4 s sentence is
already losing and never comes near 8 s, so the ladder never stepped down and
the backlog grew without bound.
It now compares against the audio the chunk actually held. Two details are
measured rather than chosen: the margin is 0.85, because the Mini's 4.4 s
against 4.5 s was NOMINALLY faster than real time while still losing — the work
outside that timer (segmenting, the preview model sharing the GPU, the
scheduler) loses on its own. And it requires a backlog of five, so one slow
sentence on a healthy machine touches nothing. Checked against eight cases
including the Mini's real numbers and a healthy M2 Max.
The old absolute rule stays for a model that is genuinely hung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Build 116.
/healthz has always carried a 'build' field, but it is a hash of the listener
page's assets — a cache-busting token, not a version. So the only way to tell
what a campus Mac was actually running was to install something and watch the
hash move, which is how the last three updates were confirmed. With an updater
in the field, what version a machine is on is the first question anyone asks.
It now answers plainly: version and buildNumber, passed to the server child from
the running bundle. Checking a campus is a single unauthenticated request.
It found something immediately: this development Mac reported appBuild 112 while
the source tree was at 115, because deploying loose files over an installed
bundle leaves its package.json behind. A packaged install reports correctly.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Build 115. Downloading and then telling the operator to quit, mount and drag
was the friction the updater was supposed to remove.
An app cannot replace itself while running, so the swap is done by a small
script that outlives the process: it waits for us to exit, moves the old bundle
aside, copies the new one in, clears the quarantine flag and relaunches.
Moved aside, not deleted. If the copy fails half way — a full disk, a truncated
download, the volume going away — the old app goes straight back and is
reopened. The failure this is written against is a campus Mac with no working
app and a service in an hour, which is far worse than not updating. Tested in a
sandbox across all three paths: a clean swap, a copy that fails mid-way (old app
restored, no leftovers), and a disk image with no app in it (aborts before
touching the installed one).
It refuses while translation is live: quitting stops every listener's captions
and no update is worth that. Stop translating first.
No sudo — /Applications is admin-writable and the bundle belongs to the
operator. If that is ever untrue the copy fails and the rollback runs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Build 114.
Translation cost is roughly linear in the number of active languages, through
one NLLB process — measured at five languages in 1.9 s. So when a machine is
running behind, the most useful single fact is how many languages it is
carrying, and that number sat one function away from the health verdict and was
never shown.
A campus reported being constantly in the red. The cause was eight languages
with 'let listeners pick any' on, against a pipeline tuned and measured against
one, and finding that took an afternoon of reading logs. The operator page now
says it in the sentence that reports the problem.
Quiet when it cannot help: nothing is added below two languages, and the
'listeners may add more' clause only appears when that setting is actually on.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Carries the in-app updater, so this is the last build that has to be installed
by hand: from here a campus Mac can fetch the next one itself.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Live sermon translation into 100+ languages, running entirely on one Mac per
campus: audio in, voice detection, Whisper on the GPU, NLLB-200 in its own
process, and a built-in web server the congregation reads from on their
phones. No audio leaves the building.
This is the source only. What used to sit beside it — 14 GB of speech and
translation models, 8 GB of voice bundles, 6 GB of natural voices, the Electron
caches, and the app data holding the operator PIN and every service transcript
— is machine state and downloaded assets, and stays in the NAS backup where it
belongs. The vendored node, cloudflared and Windows ffmpeg binaries are out too
(533 MB, re-fetched for packaging); the browser-side runtime beside them is
kept, so a checkout still serves the congregation page.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
christianandClaude Opus 5