open-git

Both halves are on main now.

#281 — the transport fix. Resumes with a Range request across up to five attempts instead of discarding what is already on disk.
#282 — a correction to what I told you above. I said Settings → About reports the expected file, then went to check and found it does not — About showed the variant and its state, not the path. It does now, as Model file, and both READMEs gained a three-step Installing a model by hand section.

So the answer to your first question, concretely:

Settings → About → Model file gives the exact path your build expects, file name included.
Download that file from openkara-models releases.
Put it there and restart.

A file whose SHA-256 does not match the catalog pin is ignored and the normal download runs instead, so a wrong or half-copied file cannot corrupt the install.

Closing — reopen if the resumed download still fails on your connection, and the log path from that same About panel is the thing to attach.

Thanks — the report is precise enough to find the bug, and it is a real one.

Why it failed. download_verified_to_temp issued a single GET, streamed it to a temp file, and deleted that temp file on any error, with no retry. The per-read inactivity timeout is 120 s (I checked reqwest 0.13's blocking Response::read rather than assuming — it wraps each read individually, so the constant does mean what its name says). So one stalled read on a slow link discarded every byte already fetched. The hour you spent was real progress; a single stall threw it away, and the next attempt would have started from zero again.

Fixed in #281. The transfer now retries up to five times and resumes with a Range request. The running SHA-256 keeps its state across attempts because no downloaded byte is discarded, so a resume costs a round trip instead of the hundreds of megabytes already on disk. Two cases are covered by tests:

a body that simply ends early — what a dropped connection looks like to the reader, since read() returns 0 with no error — resumes from the last byte instead of failing as a truncation;
a server that ignores Range and replies 200 with the whole body restarts the transfer, because appending it would corrupt the file.

On downloading it yourself: yes, that already works today, no new feature needed. resolve_model_installation checks the managed model path on startup and adopts the file when its SHA-256 matches the catalog pin. Drop the file at:

macOS — ~/Library/Application Support/com.openkara.desktop/models/
Windows — %APPDATA%\com.openkara.desktop\models\
Linux — ~/.local/share/com.openkara.desktop/models/

The file name and digest have to match the pin your build carries, and the models are published at openkara-models. I am not quoting a specific file name and hash here because the pin is per-build and I would rather not send you after the wrong artifact — Settings → About reports what your build expects.

That this is undocumented is a real gap, and it is worth a README section rather than an issue reply. Tracking that separately from the transport fix.

dev / openkara

#270 [Issue] download ONNX model failed