Build 126. Two reports, unrelated to each other.
IPHONES REPEATING AND SKIPPING PARTS OF EVERY SENTENCE.
DRIFT_LAND was 0.6 s and one segment is 0.697 s, so the position the player
was being held at sat INSIDE the newest segment — a point it very often did
not have yet. It got dragged to the edge, ran out of audio and stalled. Then
'stalled' and 'waiting' were both wired to seekLive(), and a seek on a live
HLS stream makes the element re-buffer, which raises those same two events. So
the correction caused the stall that caused the correction. On Safari, where
HLS is native and a seek lands on a segment boundary, each turn of that loop
replays or drops a piece of a sentence — which is exactly what was described.
Three changes, all of them about not fighting the player: those two events no
longer seek, the target is three segments back (~2.1 s, what an HLS player
picks for itself on a live playlist), and a correction now has 5 s to settle
before another may run. Costs about 1.5 s of extra delay. A listener a second
further behind is following the service; one whose audio keeps jumping
backwards is not.
NOT YET CONFIRMED ON A REAL IPHONE — the mechanism is read off the code and
the measured segment length, and the next service is the test.
CANNOT SCROLL THE MONITOR WHILE LIVE.
Four boxes ended their update with box.scrollTop = box.scrollHeight,
unconditionally, so every sentence yanked the view back to the live edge and
reading back was impossible. They now follow the bottom only while the
operator is already at the bottom, and resume when they return — nothing to
press either way. Trimming the top is held off while they are scrolled away
too, since dropping old lines moves the text being read; the cap comes back
the moment they return, with a ceiling so nothing grows all service.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Build 125. Reported from the desk: every language on the listener page can be
switched off except English.
Exactly right, and it was not subtle. renderFeatured() unshifted the SOURCE
language into the list on every render, whatever the operator had chosen:
if (list.indexOf(app.cfg.sourceLanguage) === -1)
list.unshift(app.cfg.sourceLanguage);
So English was not merely on, it was always FIRST — the leading button on the
page — on a desk whose saved list was ["spa_Latn","por_Latn","por_PT","spa_ES"]
with English deliberately off and allowAll false. The operator had turned it
off, the config recorded that it was off, and the page put it back anyway.
The reasoning behind it was sound: people do want the English captions for
accessibility rather than translation. But that is a choice for the desk, not
for this function, and the switch to make it is already there in Settings next
to every other language. English is in the catalogue (languages.js:19) and the
operator window reads that same file, so turning it back on is one click.
A control that silently refuses is worse than no control. The operator's list
is now the list.
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