[BUG] Partial downloads prevent the model from ever being downloaded again

[iKlsR]

Installed the app on a brand new pc for the first time and attempted to download the recommended Parakeet V3 model. The download progress seemed to be fine until it reached the extracting step which was taking an abnormally long time, I ended up killing the app and then attempted to re-download the model again. This refused to work as it would seem to trigger and move it to the top but it would then reappear in the model list. Tried a couple other models which were able to be downloaded just fine.

On further inspection, there seemed to be a Partial Download in the AppData folder, deleting this then allowed me to download the model again.

In conclusion, I believe the problem to be two-fold, it seems to hang at the extracting step for some models (seems to be the parakeet ones from my testing), a frustrated user would then attempt to restart the app which would then leave it in a broken state.

My suggestion would be to scan for incomplete models/unrecognized files and indicate accordingly in the list (red bg with exclamation) and allow the user to delete these to restart the process or on startup automatically purge these which presumably should be non .bin files. Additionally, investigate why the extracting process would run upwards 10 minutes on a successful download.

0.7.6, Windows 10, i7 8700k, GTX 4090

cc @VirenMohindra

[cjpais]

Yes this is an issue, I ran into the same thing while setting up my windows machine yesterday

There are two issues

1. We need better UI to indicate the extraction and subsequent loading of the model takes time. I believe it's primarily the loading of the model that seems to freeze things. Why it took 10 minutes for you, I'm very surprised, I have a much less powerful machine and it took 30 seconds. A log might be helpful on this, and especially if you can replicate again

2. I think partial downloads are just broken. We've tried to fix them multiple times, I'm not sure it's worth it at this point. I think we should just checksum and if the checksum does not match, delete the file and re-download

[iKlsR]

We need better UI to indicate the extraction and subsequent loading of the model takes time. I believe it's primarily the loading of the model that seems to freeze things. Why it took 10 minutes for you, I'm very surprised, I have a much less powerful machine and it took 30 seconds. A log might be helpful on this, and especially if you can replicate again

As at this time, I'm still unable to move beyond extracting for Parakeet V3 (I can see the blob and the .extracting folder but that's it), I had just reported that it spent about that time with no progress. I was doing some trial and error with all the models to see if the flavor had anything to do with it but nothing conclusive, some work, some don't with no clear pattern. Meanwhile whisper medium downloads and sets up in no time every time, very odd.

I'm not sure it's worth it at this point. I think we should just checksum and if the checksum does not match, delete the file and re-download

Simple and clean, my exact thought for the check and just prune these. Tho it's worth noting that in my case I think the download completed, just the consequent step hung so there might be an in-between solution for these cases vs an interrupted download at say 30%.

[cjpais]

Could you get a log for parakeet, I assume it's not the extracting bit as the issue but the model loading? What happens if you manually unzip/untar the model will the app let you click it as a model and will it load

[iKlsR]

Following the detailed readme (thanks), yes manually extracting the blob the model works and loads quickly. I enabled debug logs but not seeing anything appear in any of the app directories in the form of a log.

[VirenMohindra]

the root cause is in the extraction failure path in model.rs (around line 965). when archive.unpack() fails, the .extracting temp directory gets cleaned up but the .partial file is NOT deleted. on the next download attempt, the app sees .partial, resumes from EOF, thinks the download is "complete", and retries extraction on the same corrupt archive — infinite loop.

the fix is one line — let _ = fs::remove_file(&partial_path); in the extraction error handler. included it in #1051 (commit 0c14750).

PR #1015 also fixes this but with ~95 lines of additional error handling. the one-line version breaks the loop; checksums (as @cjpais suggested) would catch corruption even earlier.