v1.4.0 - Resume interrupted downloads
Resume an interrupted download
If KineTube is closed - or crashes - while a video is downloading, the next launch now offers to pick up where it left off instead of losing the progress.
- A small banner appears on the YouTube tab listing any download that was still in flight the last time the app closed
- "Resume" re-issues the exact original request; yt-dlp resumes its own partial file automatically rather than starting over
- "Dismiss" clears the prompt without restarting it (the partial file is left on disk untouched)
- A download you cancel normally is never offered back as "resume" - only one cut off by the app itself closing
This only covers single-video YouTube downloads for now. Bulk batches and Instagram downloads aren't tracked by this yet - see the roadmap.
Under the hood
One shared download helper, not two drifted copies. The yt-dlp/ffmpeg manager and the whisper.cpp manager each had their own copy of the same download-with-progress function, and the copies had quietly drifted apart - the whisper.cpp version correctly cleaned up after a dropped connection mid-download, the yt-dlp version did not (it could hang indefinitely instead of failing). Both managers now share one implementation, using the more correct behavior.
A centralized api.js on the frontend. Roughly 20 request call sites across 6 components were each rebuilding the same "send JSON, parse JSON, handle errors" logic by hand. Pulled into a small shared module so that logic exists once. No user-visible behavior changed - this is pure internal cleanup.
Fixed a test-infrastructure gap that let a leftover element from one component test silently affect the next test in the same file.
Downloads
| Platform | File |
|---|---|
| Windows | KineTube-Setup-1.4.0.exe |
| macOS (Intel) | KineTube-1.4.0.dmg |
| macOS (Apple Silicon) | KineTube-1.4.0-arm64.dmg |
| Linux | KineTube-1.4.0.AppImage |
Full Changelog: v1.3.1...v1.4.0