You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(settings): ask before downloading a newly selected model (#152)
* feat(settings): ask before downloading a newly selected model
Saving a transcription model change queued a download as a side effect.
That download runs on the GPU lane, the same lane that serves live
transcription, so on a single-card host it could sit in front of a
meeting; nothing in the UI said it had started, and the setup wizard's
promise to "check progress later in Settings" was never honoured.
Preparation is now explicit. Selecting a model that is not on the server
prompts for a choice: fetch it now so it is ready for the next
recording, or leave it to the lazy fetch on first use, which delays live
transcription and Meeting Edge until the download completes. Selecting a
model already on disk saves silently, so the prompt only appears when
there is something to download.
A new admin-only POST /system/models/prepare carries the request, with
targets for the active selection, the core batch, and each ONNX ASR
model, so a single missing row in Model dependencies can be repaired on
its own. It refuses a second request with 409 while one is in flight,
and resolves the model from the admin's own settings rather than the
install config, since the transcription keys are user-scoped and reading
config alone would prepare the install default instead.
Model dependencies gains a Download action on every missing row plus a
live progress strip, so declining the prompt is recoverable and a
running preparation is visible however it was started.
Saving settings through the API no longer prepares models for any
caller. Lazy fetch on first use still covers that path.
Refs: docs/DEPLOYMENT.md, docs/ADMIN.md, docs/USAGE.md
* fix(models): detect cached ONNX ASR models by their repo name
Canary was reported as missing however many times it was downloaded.
The status check matched the Nojoin model id against Hugging Face cache
directory names, but onnx-asr caches nemo-canary-1b-v2 under the repo
istupakov/canary-1b-v2-onnx, so the id never appeared in the directory
name. Parakeet escaped the bug only because its id happens to be a
substring of its repo name.
Match a fragment of the repo name instead, held in one named map with
the divergence written down so it is not "corrected" back to the model
id later. Resolving the id through onnx-asr would be exact, but that
would pull the ASR stack into the API process, which the torch boundary
test exists to prevent.
This also unblocks deletion and the admin health card, both of which
read the same status: a model reported as missing has no resolvable path
to delete, and the transcription component showed Canary as uncached.
Refs: backend/preload_models.py
* fix(models): delete cached models from a worker, not the API
Deleting a model failed on every Docker install with EROFS. The API
mounts the shared model volume read-only, by design, so the delete could
never have worked from there: the failure was structural rather than a
bad path.
Dispatch the delete to the io lane, which mounts that volume read-write
along with the other worker lanes. The task resolves the path itself
rather than accepting one from the API, because the same volume is
mounted at a different path in each container, and a delete sink that
trusts a caller-supplied path is worth not building. It returns a status
dict instead of raising, since the JSON serialiser would not carry the
difference between "not found" and "refused" across the boundary.
The request still waits for the result, so the UI can keep refreshing
model status the moment it returns, with a 60 second ceiling that fails
the request rather than holding a thread when no worker answers.
Deleting a model now needs a running worker; that is documented.
Refs: docs/DEPLOYMENT.md, docs/ADMIN.md
0 commit comments