* refactor(launchpad): quieter, borderless design refresh The launchpad carried decoration from an earlier direction: icon chips, corner-hung count badges, a permanently visible filled arrow, uppercase mono card titles, and a dotted stipple divider — plus a frame that had been invisible since the app-wide border tokens were zeroed. Rework it around what the borderless direction actually implies: - Feature tiles get a whisper-faint surface instead of a dead frame, and read as three bands (bare glyph + count / title + arrow / description). `--card-hue` is spent sparingly — the glyph at rest, the surface, count and arrow only once raised. Titles move to sans sentence case; counts are plain tabular numerals. Lift softened 4px -> 2px, coloured glow -> neutral shadow, plus an explicit focus ring and a staggered entrance. - Hero drops the boxed "646" pill and the filled A/B-Compare button for quiet type, with a hairline standing in for the separation. - Section labels trade the dotted stipple for a single fading hairline; rows are transparent until hover and reveal "Open" on hover/focus (it stays in the DOM, so AT and keyboard always reach it). - Hero, tiles, recent files, callout and project lists now share one 1180px column — previously only the top half was capped, so lists ran edge-to-edge on a wide display while the deck stayed centred. Two bugs found and fixed while doing it: - Buttons that had `border border-solid border-transparent` removed fell back to the UA default border and rendered a visible 1px outline. They now carry `border-0` explicitly. - `.lp-animate` used `animation-fill-mode: both`, so after the entrance it kept owning `transform` — and animation-origin declarations outrank normal ones, which silently killed the card hover lift. Now `backwards`, which still holds the from-state through the stagger delay. Also drops CSS the page has not rendered since #904: the cursor-spotlight layer, the breath ring, and the per-card waveform strip. Verified with headless renders at 1600/1280/940 and the empty state. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(dictation): decode Wayland portal signals and show the capture pill The GlobalShortcuts portal declares Activated/Deactivated as (o session, s shortcut_id, t timestamp, a{sv} options). We decoded the timestamp as u32, so zbus rejected every signal with Signature mismatch: got `(osta{sv})`, expected `(osua{sv})` and the press was dropped as an invalid signal. Registration succeeded and the desktop even reported the bound chord back, so the hotkey looked wired up while doing nothing at all — on every Wayland compositor, for the whole life of the feature (#1490). Decode the 64-bit timestamp, and keep the 32-bit spelling as a fallback so a non-conforming portal degrades to working rather than to silence. With presses arriving, the second half of the failure showed: nothing had shown the widget window since it became a hidden recorder host, so a capture ran with no pill on screen — and a mic or Accessibility failure rendered into a window nobody could see. Add show_dictation_pill, which bottom-centres the capsule on the monitor under the pointer and shows it without taking focus (Windows keeps SW_SHOWNOACTIVATE so paste still lands in the user's document), and call it from the widget for every state but idle. Wayland denies clients their own placement, so the compositor picks the spot there; the pill still appears. dispatch_dictation_capture now logs whether a press was emitted or queued — a press that reaches Rust and produces nothing was otherwise indistinguishable from one the compositor never delivered. Tests: portal signals decode at both timestamp widths (the 64-bit case fails before this change with the exact production error); pill placement centres, respects a second monitor's origin, and clamps rather than going off-screen; the widget shows for a state needing the user, stays hidden while idle, and never shows for a press that arrives while dictation is disabled. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chore: sync in-progress workspace changes Uncommitted work already in the tree, checkpointed so the branch matches the local machine: - Remote GPU workers: join-from-the-app flow, one-time secrets, QR join codes, a Compute control in the status bar, and the device-list Workers panel (#1516) - Model Catalogue workspace, with Settings pointing at it - Settings sidebar search and keyboard navigation - Demo assets for dubbing, dictation and voice design, plus the scripts that render them - Backend: validation-error handling, ASR request-path degradation, and the accompanying tests - CHANGELOG entries for the above and for the Wayland dictation fix Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tests): follow Engines to the Model Catalogue, and green the sweep - test_supertonic3 asserted the license gate points at "Settings" while the engine now names Model Catalogue → Engines, which is where the accept button actually lives. The assertion follows the move; what it pins is unchanged — the hint must name a place the user can reach it. - Carries the CJK allowlist entries for the rendered dub bundle (#1517) and the regenerated route snapshot for /workers/agent (#1516), both of which this branch inherits from the workspace sync. - docs/install/linux.md: the dictation capsule is bottom-anchored everywhere except Wayland, where the protocol gives applications no say in their placement. Documented rather than left as a surprise (CodeRabbit). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: stop a flaky dependency fetch from failing green runs en-core-web-sm resolves to a direct GitHub release URL, and github.com intermittently answers `http2 error: refused stream before processing any application logic`. uv's own three retries all land within the same few seconds and fail together, so the whole job dies on a dependency that has nothing to do with the change under test — it cost #1518 and #1517 an otherwise-green run tonight. Two changes: back off between whole `uv sync` attempts, which is what actually clears it, and pass --no-sync to the pytest steps. `uv run` re-resolves the environment before running, so every test step was a fresh chance to hit the same fetch even though the install step had already synced — that is exactly how #1518 failed, in the isolated backend/tests step, with all 5467 tests already passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: one retry seam for every uv sync, not just the job that failed last en-core-web-sm resolves to a direct GitHub *release* URL rather than a package index, and github.com intermittently answers `http2 error: refused stream before processing any application logic`. uv's own retries all land inside the same ~10 seconds and fail together, so a job dies on a dependency unrelated to the change under test. Tonight that cost four otherwise-green runs across #1515, #1517 and #1518 — and the first fix only covered the Tests job, so the next failure simply moved to Smoke (Linux), which syncs separately. The fetch is per-job, so the fix has to be per-job: scripts/uv-sync-retry.sh backs off between whole attempts (15s, 45s, 90s) and every workflow that syncs now goes through it — ci.yml (tests + the platform matrix), release.yml, security.yml, evals.yml. It still fails loudly after four attempts, so a genuinely broken lockfile is not disguised as a flake. The Tests job also lacked the UV_HTTP_TIMEOUT / UV_HTTP_RETRIES the smoke matrix has always set, which is part of why it was the one that kept dying; it has them now. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(ci): pin the Intel-Mac contract by intent, not by command spelling test_ci_verifies_intel_mac_as_the_documented_remote_only_host asserted the literal line `run: uv sync --extra pockettts`, so routing every sync through scripts/uv-sync-retry.sh read as a broken Intel-Mac contract. The contract it exists to protect is that the pockettts extra installs ONLY on backend_supported legs — which the regex now pins, while leaving how the sync is invoked free to change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: keep every uv run out of the resolver, and bound the retry budget CodeRabbit, #1517: - `uv run` re-resolves before running, so the smoke suite, the worker-artifact tests, the release test run and the eval run were each a fresh chance to hit the flaky direct-URL fetch outside the retry loop. All of them pass --no-sync now; the environment is already synced by the step that owns the retries. security.yml's `uv run --with pip-audit` is deliberately left alone — it layers an ephemeral package rather than running the project's own tests. - The retry count multiplied uv's own budget (UV_HTTP_RETRIES=5 with a 120 s timeout on the smoke matrix). Three attempts and 60 s of total backoff outlast the refusals actually observed while staying well inside the jobs' timeout-minutes. - The Intel-Mac contract test pinned the smoke command literally too, so --no-sync tripped it exactly like the sync line did. Same fix: assert the contract (smoke runs only on backend_supported legs), not its spelling. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
8.6 KiB
Downloading models — speed & troubleshooting
VoiceStudio downloads models from the Hugging Face Hub on first use. This page explains how downloads are made fast, how to read the progress, and what to do on slow or restricted networks.
When a remote GPU is selected, the catalog is filtered and curated for that
worker's reported OS, architecture, and GPU backend—not for the control-plane
computer. Generation checks the worker's capability report before submitting a
job. If the required weights are positively known to be absent, VoiceStudio
shows “model not downloaded on <worker>” with a download action. The download
runs on that worker and refreshes its capabilities when it finishes; press
Generate again afterward (the interrupted job is not automatically resubmitted).
The same POST /models/install request targets either local or the selected
worker, and /setup/download-stream reports both with a target field. Progress
is tracked by (target, repo_id), so simultaneous downloads of one model on two
machines remain separate. Workers receive only an opaque model identifier and
resolve the reviewed Hugging Face repository and pinned revision from their own
catalog.
Unknown or user-managed cache layouts are allowed through so existing manual
engine installs remain compatible.
Managed sidecar engines are intentionally excluded from remote installation. Their current installer fetches mutable source before creating an editable environment; install those directly on the worker until that source is pinned.
Download backend: legacy LFS by default (accurate progress)
VoiceStudio ships hf_xet (Hugging Face's chunked, parallel, dedup transfer
backend — the IDM/uGet-style fast path), but currently runs with Xet
disabled (HF_HUB_DISABLE_XET=1, set by the app). Reason: Xet's transfer
reports progress out-of-band and bypasses the byte-level progress hook, so the
download UI couldn't show real bytes/speed. Until a proper Xet progress hook
lands, the app forces the classic LFS path, which streams through the
standard progress reporter and gives accurate downloaded/remaining/speed.
To keep that path fast despite Xet being off, the app runs a built-in
multi-connection (segmented) downloader on by default — it fetches each file
over parallel byte-ranges (IDM/uGet style), so the legacy-LFS path is no longer
single-stream. It reports real live speed/ETA and falls back to the normal
download on any error, so it can never compromise a correct install. Adding a
free Hugging Face token (first-run setup, or Settings → Credentials) makes this
faster still — authenticated downloads get higher rate limits and fewer stalls.
To force the old single-stream path, set OMNIVOICE_SEGMENTED_DOWNLOAD=0.
State is reported at Settings → About / GET /system/info:
fast_download.xet_installed—hf_xetpresent (true)fast_download.xet_active— whether Xet actually drives downloads (false by default, because ofHF_HUB_DISABLE_XET)- the ⚡ fast download badge in Model Catalogue → Models appears only when Xet is active.
The backend logs one line at startup, e.g.
downloads: Xet disabled → legacy LFS (hf_xet 1.4.2 installed=True).
Re-enabling Xet (advanced, opt-in)
Power users who want Xet's speed and don't mind coarser progress can set
HF_HUB_DISABLE_XET=0. With Xet active, the overall bar advances by file and
snaps to the exact total on completion (per-file byte speed isn't shown,
which is exactly why it's off by default). Xet needs a 64-bit OS (all supported
VoiceStudio platforms).
Reading the progress
When a download starts you'll see, in order:
- Resolving — the app fetches the file list and computes an exact plan: total size, how much is already cached, and how much will actually download (shown before any bytes move).
- Downloading — one overall bar with the file count (e.g.
3/7 files), total size, and — on networks where per-byte progress is reported — live speed and ETA. - Done — the bar lands on 100% at the true total size.
Note: the exact total and "already cached / to download" split are known up front (a pre-flight resolve), so remaining is accurate from the start. Live per-byte speed appears once a file is large enough to stream over several seconds; very small/fast files may jump straight to done. The bar always lands on the exact total at completion. (If Xet is re-enabled, progress becomes file-granular — see above.)
Advanced / opt-in tuning
These apply to every platform identically. Set them as environment variables (or
via Settings → API keys / environment). The segmented accelerator is on by
default (set its var to 0 to disable); the rest default off.
| Setting | Env var | Effect |
|---|---|---|
| Segmented accelerator | OMNIVOICE_SEGMENTED_DOWNLOAD=0 |
On by default (see above). Set to 0 to force the old single-stream legacy-LFS download instead of the parallel byte-range one. |
| Max parallel files | OMNIVOICE_DOWNLOAD_MAX_WORKERS (default 8) |
Files fetched at once. Xet already parallelises within a file, so raising this rarely helps and uses more memory. |
| High-performance mode | HF_XET_HIGH_PERFORMANCE=1 |
Maximum throughput. Needs lots of RAM and bandwidth — can hurt low-RAM machines. Leave off unless you have headroom. |
| Spinning-disk (HDD) | HF_XET_RECONSTRUCT_WRITE_SEQUENTIALLY=1 |
Sequential writes; avoids parallel-write thrash on HDDs. Leave off on SSD/NVMe. |
Restricted networks / mirrors (e.g. China)
Automatic (the default). When no endpoint is explicitly configured,
VoiceStudio picks one for you: it probes huggingface.co and the community
mirror hf-mirror.com in parallel (short HTTPS reachability + latency
checks — no geo-IP lookups, no third-party services; your device
language/timezone only decides which endpoint is probed first), prefers the
official endpoint unless the mirror is decisively faster, and remembers the
winner. The decision is re-tested only on the first-run system check, after a
network-classified download failure (the failed download retries once on the
new winner), when it's more than 7 days old, or when you press Test again
in Settings → Models → Hugging Face mirror. Mirror integrity is a
non-issue: huggingface_hub verifies every download by checksum regardless
of endpoint. Opt out with OMNIVOICE_HF_ENDPOINT_MODE=manual.
Explicit (always wins). To pin an endpoint yourself:
HF_ENDPOINT=https://hf-mirror.com
Set it in Settings → Models → Hugging Face mirror (quick-pick presets and a custom URL — any explicit choice switches the panel to manual mode and is never auto-switched), or as an environment variable before launching. On first run, the setup wizard's network check reports which endpoint the automatic selection picked, and still offers the mirror quick-pick when nothing is reachable — the check is a warning, not a blocker, so an offline or firewalled machine can still finish setup once models are available (mirror, or manual download below). If a wizard download fails because the configured mirror is unreachable, the same quick-pick (including Hugging Face (official)) appears right next to the failed row — switching applies to downloads immediately (no restart; only already-loaded engines re-read the endpoint at startup), clears the retry cooldown, and retries the failed download at once. Caveats:
- A mirror serves the classic download path, not Xet — you lose chunk-dedup and Xet's parallel fetch, but you gain reachability. On the classic path, per-byte speed/ETA is shown continuously.
- Russia and some networks have no official mirror; use a VPN/tunnel.
Cancelling a download
Model Catalogue → Models lets you cancel an in-flight install. Cancellation stops further retries and clears the failure cooldown so you can restart immediately. A file that's already streaming finishes first — cancellation takes effect at the next retry boundary.
Troubleshooting
- Stuck on "Resolving…" — the Hub is slow to return metadata, or you're rate-limited without a token. Add a token (see docs/setup/huggingface-token.md) and retry.
- Very slow / stalling — try a mirror (above), or a wired connection. High-performance mode only helps if RAM and bandwidth are plentiful.
- "download finished but no model weights were found" — the download was interrupted and left a partial snapshot. Delete the model in Model Catalogue → Models and install it again.
- Out of disk — model sizes are shown in the catalog; free space or change
the cache location with
HF_HOME/HF_HUB_CACHE.