Repository navigation
Setup never tells the user which models failed to download #604
Description
Activity
Partly fixed in #606, landed on main as 53a6c04.
setup.js now reads the warmup result and names anything that did not download, in the log that gets attached to bug reports.
Worth recording why this was nearly worthless: the first version read the Rust field names, but ModelWarmupStatus is #[serde(rename_all = "camelCase")], so all four were undefined and the warning could never fire. It was a no-op that looked correct, and it was verified by reading the struct rather than its wire format. Review caught it.
The visible half is deliberately not done here. The setup wizard's status line is overwritten by the next step and then the window navigates away, so nothing written there can be read. Telling the user properly belongs in the main UI next to the feature that is actually degraded, and that is its own piece of work. Closing this as the reporting gap it described; reopen or file fresh if the in-app surface is wanted.
What happens
warmup_modelsreturns a per-modelModelWarmupStatussaying exactly which of the four models came down and which did not.desktop/ui/setup.jsthrows the value away.So a user whose beat model never arrived sees a clean, successful setup, and then a permanently worse beat grid, with nothing at any point connecting the two. There is no message, no log line, and nothing in the UI.
Why it matters more than it looks
The degraded state is genuinely invisible from the outside. Beat detection falls back to librosa, which looks exactly like a machine that never had the model. The karaoke split just reports itself unavailable. Neither says why, and neither points at setup.
This is the piece that turns #603 from a bug into a bug nobody can report, because the user has no reason to suspect their models at all.
Constraints
desktop/ui/setup.jshas no i18n layer at all (no import, all strings hardcoded), unlike the web UI instatic/. Anything added there does not go through the language tables.