Deluge
I've added over 400 torrents to Deluge, as part of a migration from Transmission so that I could take advantage of some Deluge plugins. They all added fine, I have LabelPlus installed and the rules I've setup there all worked as expected, setting download locations correctly. These torrents all match existing files, when I force re-check a torrent, it completes correctly and seeds as expected.
The problem is that it's not queuing re-checks. As many as I select to force re-check, it will try to check simultaneously. If I simply resume them, they start to download without running a check first (which I don't even understand tbh, I don't see duplicate files created...). This is going to take me weeks if I have to manually select a handful at a time to check them.
Has anyone else seen this? I've used Deluge in the past and my memory is that it will queue re-checks, probably using the same queuing rules as downloads?
The daemon is running on OMV 4.1 using an armhf Docker image from linuxserver.io, and I'm managing it with the Mac GTK client.
As an aside if anyone has recommendations for settings to improve performance, that would be great. Even with this middling torrent volume, the daemon seems pretty sluggish to respond to the client.
Queue force re-check of multiple torrents at once
Re: Queue force re-check of multiple torrents at once
I've just begun to experience this behavior in 1.3.15. I'm certain rechecks were done one-by-one in the past. I have a large session, but that shouldn't matter. Is this a known issue that has been dealt with in 2.0.x?
As for performance tips, if you're still stuck with Deluge 1.3.x like I am, its performance is largely based on size of the state or fastresume file (or both), and only single core processing power seems to improve it. When overclocking the same processor from 3.2 to 3.7 GHz, I noticed an increase of several hundred in the number of torrents I could run simultaneously without having to disconnect and reconnect after every single command from the thinclient (meaning one command per three minutes, at best, and depending on the size of the operation, it can mean one command every few hours, with no GUI updates for the client until the daemon has finished). The daemon becomes slower and slower to respond up to a point. After that, it never responds, or the client never receives the response, as it will stay 'connected' for 24 hours without updating, even though the prior operation (such as removing a single torrent) has long since completed.
So yeah, no tips except optimize clockrate/iops.
As for performance tips, if you're still stuck with Deluge 1.3.x like I am, its performance is largely based on size of the state or fastresume file (or both), and only single core processing power seems to improve it. When overclocking the same processor from 3.2 to 3.7 GHz, I noticed an increase of several hundred in the number of torrents I could run simultaneously without having to disconnect and reconnect after every single command from the thinclient (meaning one command per three minutes, at best, and depending on the size of the operation, it can mean one command every few hours, with no GUI updates for the client until the daemon has finished). The daemon becomes slower and slower to respond up to a point. After that, it never responds, or the client never receives the response, as it will stay 'connected' for 24 hours without updating, even though the prior operation (such as removing a single torrent) has long since completed.
So yeah, no tips except optimize clockrate/iops.