Backchannel v0.6.3
Backchannel v0.6.3
A fix release. Local transcription did not work in v0.6.1 or v0.6.2. A meeting
run with a local model recorded audio, separated speakers, and saved no
transcript at all.
Highlights
- Local transcription works. The desktop bundle shipped without files the
speech library reads on every transcription. v0.6.2 fixed one missing piece
and shipped without the next one underneath it, so the symptom stayed the
same while the error changed. Both are fixed, and the build now fails rather
than shipping without them. - Your recordings are recoverable. The audio from meetings that produced
no transcript is still on disk. Open the session and choose Re-transcribe to
rebuild the transcript from it. - The app no longer claims to be ready when it is not. Readiness checked
only whether the speech library could be named, not whether it could run, so
it reported transcription as ready through both broken builds and failed
every job in silence. It now proves the engine works, and names the actual
fault when it does not. - Re-transcribe will not erase a transcript it cannot replace. It deleted
the existing transcript before replaying audio, so a transcriber that could
not run turned the button into an erase. It now refuses up front and leaves
the session untouched.
Notes for operators
The two packaging faults are the same class, one layer apart. onnx-asr reads
its own version through importlib.metadata at import (fixed in v0.6.2 with
copy_metadata), and reads preprocessors/data/fbanks.npz plus a set of
.onnx front-end graphs through importlib.resources at transcription time
(fixed here with collect_data_files). PyInstaller ships neither unless the
spec asks for it, and the spec now aborts the build if the data collection
comes back empty.
local_asr_available() was importlib.util.find_spec("onnx_asr") is not None. Both broken bundles satisfied it. The probe now imports the package and
resolves the resources its preprocessors open, needing no model weights and no
network, and caches the result. GET /api/diagnostics/local-asr reports it.
The release smoke test previously only started the bundle and waited for
/api/health; a broken bundle starts perfectly well. It now calls that probe
against the running bundle and fails the build, which is the gate that would
have caught both v0.6.1 and v0.6.2 before publication.
Known and tracked separately: re-transcribing a long recording holds one
request for the whole replay and its CPU-bound diarization starves the event
loop, so the rest of the app stops answering and there is no progress to
watch. It is working, not stuck.
Upgrading
An install on v0.5.3 or later updates itself in place and verifies the new
build's signature before applying it. An install on v0.5.2 or earlier will
not see this release from inside the app: download the bundle from the
release page, quit the old version from the tray, and run the new one.
After updating, re-transcribe any session that came back empty; the audio is
still there.