Deluge Rechecks Move On Complete Files on Startup

[DrSexyMD]

Hello. I have two folders set up to organize my downloads, an "Incomplete" folder for things currently downloading, and a "Completed" folder that Deluge is set to automatically move all downloads to after finishing the download using its "Move Completed To" option in the settings. I'm running Deluge in Docker using the binhex/arch-delugevpn:latest image. My problem is that whenever Deluge restarts, it doesn't remember that the files have been moved and starts redownloading basically every torrent in the list. Is there a way to fix this other than to stop moving files on completion (or removing torrents from the client)?

[mhertz]

Seemingly deluge doesn't close gracefully, from sounds of it. This should be fixed about 6 months ago by binhex, but maybe not 100% still, or maybe some later update to dumb-init or alike, broke it again, not sure. I'm not 100% sure honestly if even this is the issue, as sounds little strange that even move-completed status forgotten, and not just e.g. settings etc, well probably related to resume data, written at shutdown so makes sense possibly anyway, sorry somewhat discussing with myself here seemingly

Without testing this in detail and looking how behaves during docker exec and pkill sendings etc, then all I can suggest is to make sure deluged closed properly, e.g. deluge-console -c <config-location> halt, or from e.g. webUI(or GTK-UI) to from connection manager close the daemon, a trick I remember the good ambipro used to state doing, to workaround this(ungraceful shutdown) in older times, on the sister image(non-vpn), the former could be presumably scripted for OS restarts/poweroffs, e.g. systemd service/drop-in before shutdown target etc., and then reporting this on the issues section of binhex's github would be good i'd say, if wanting it fixed.

Good luck.

[ambipro]

I haven't experienced this except for when cross-seeds were not moved and disassociated with the files. binhex has a script that runs that automatically rechecks (and subsequently downloads if missing) error'd torrents.

This should be unnecessary from my testing now that the problems were resolved some six months ago with exiting gracefully, however it is still present and if files are found to not be there upon recheck it will continue to download again.

You can comment out the line in the script, and it should remain in the error state rather than redownloading, however it's curious that you would see this problem at all if the container was not abruptly killed or something if you are running on the latest.

This is the line, its in /home/nobody/ if you want to try commenting it out.
https://github.com/zakkarry/arch-deluge ... sh#L34-L35

As for the not saving, it does indeed sound like you are not shutting down gracefully.

[mhertz]

Good catch ambipro, I didn't think of that honestly

[DrSexyMD]

This should be unnecessary from my testing now that the problems were resolved some six months ago with exiting gracefully, however it is still present and if files are found to not be there upon recheck it will continue to download again.

You can comment out the line in the script, and it should remain in the error state rather than redownloading, however it's curious that you would see this problem at all if the container was not abruptly killed or something if you are running on the latest.

As for the not saving, it does indeed sound like you are not shutting down gracefully.

Therein lies my problem. There have been several strong storms near me lately that shut the power off for long enough that my battery backup was unable to keep my computer online, after which it started redownloading everything. It would be nice if there was a way to prevent it from having this issue on non-graceful shutdown as well. Does Deluge basically just check the main Downloads folder for everything automatically on restart after a non-graceful shutdown? I suppose I could just stop moving completed files if it'll fix this issue.

[ambipro]

i mean by definition a non graceful shutdown is non graceful. you can configure most os to shutdown when battery gets low gracefully with simple packages... unraid uses apcusbd i think its called.

the big issue is the recheck script i referenced. it will otherwise just stay as error and not download.

[mhertz]

I don't get it honestly. State/resume saved every 3 minutes, so even if battery dies, and hence script rechecks, but wouldn't it look at old state/resume and hence find new path? Unless timing within said 3 mins - could be wrong. There's a plugin where you can change these times BTW, im pretty sure I once made.

[ambipro]

Yes, you did. I use it.

viewtopic.php?p=235332&hilit=statesave#p235332

[ambipro]

Further note, unless the file is corrupted, and then reverts back to the .bak file - I'm not sure how long of an interval it uses, perhaps it only saves on startup?

Either way, the proper solution would be to comment out that line for torrentcheck.sh - which should be unnecessary - and implement a shutdown gracefully script using one of the available UPS package management things. None of those are overly complex to do, and would make this problem pretty much avoided altogether.