A download stopped by a restart waits for its feed's next check #410
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A file download is never marked 'downloading' (only torrents are), so one under way when the daemon stops is left 'pending', which is right, but requeue_interrupted has nothing to do and nothing else picks it up early: the first pass after a start scans only the feeds that are due, and pending files are fetched in a scan of their feed. After a deploy, an episode that was half downloaded waits until its feed is next checked, an hour on the default schedule and a day for a daily one. Found writing the daemon test for #400, which saw the episode not asked for again in 60 s after a restart. The first pass could download what is pending for every feed, due or not, or a download could be marked 'downloading' while it runs so requeue_interrupted brings it back.
Fixed in
7994f93: fetch_one marks a file 'downloading' while it runs, as torrents were; requeue_interrupted returns the ids it puts back, and the daemon queues a download of each before it serves, whatever the feed's schedule. crates/ipx/tests/daemon.rs checks a daemon restarted mid-download asks for the episode again within seconds. Deployed as 1.5.2-dev.