On Thu, 2025-11-27 at 06:35 +0100, Daniel Baumann wrote: > Hi Lyndon, > > On 11/26/25 21:28, Lyndon Brown wrote: > > most of the time such actions to skip or > > un-skip (by selecting a priority) a file have no effect. > > yes, the behaviour doesn't seem obvious - while 'skipping' files > means > that they are not put into the target directory, they are sometimes > still (in parts) downloaded and stored in one large 'hash file' > (.$hash). > > While this can be beneficial from the point of "sharing content to as > many peers as possible" even if you choose not to want it in the > first > place, it's not desirable from to individual point of view and I'm > not > aware of any configuration option to change this. > > However, this is a "fundamental" behaviour of deluge and there's > nothing > I can do on the Debian side. > > Can you please report this upstream in their tracker: > > https://dev.deluge-torrent.org/ > > Regards, > Daniel
Hi. You've misunderstood the problem. I'm not concerned about whether or not partial files end up in the downloads folder, or whether or not odd fragments of unwanted files arrive and get stored somewhere. Imagine a TV remote control with low batteries and having to repeatedly press a button over and over, with nothing happening, until eventually you press it and it finally works. That's in effect what's happening here. When you perform a change-file-priority action, it reliably updates the priority field of the files table, but very frequently the rest of what needs to take place never happens, as though it gets interrupted, or bad timing causes a condition to fail, and the work to complete the action gets abandoned. If you then repeatedly toggle priority, and not necessarily for that file, but for any file in the torrent, eventually one of these actions fully completes and any altered file priorities are fully processed. The most obvious indicator of whether or not an action has actually completed, and thus the change in priority has fully taken effect, is the size of the torrent shown in the main download table. When an action to skip/unskip a file fully completes, the size of the torrent will increase or decrease accordingly (presuming the files excluded/included are significantly large enough for the difference to be noticed, and presuming the set of differences amount to a different total size). When the action doesn't complete then the size doesn't change. When an action fully completes, and the size of the torrent changes correspondingly, only then will it try to avoid downloading any more of any files newly marked skip, and to download or resume downloading any files newly un-marked skip. Whether or not the torrent is paused makes no difference to reliability. I did look at their website with a mind to possibly reporting upstream, but their website is implementing a bot check and stupidly blocking me. I tried one or two things to get around it but gave up. So could you please upstream it for me. Thanks. If it's still not clear enough, imagine the following. Say I have a 2GB torrent made up of 4x 500MB files. If I change the priority of one of those files to 'skip', then the displayed priority in the files table will be updated to reflect this, but typically nothing else will happen. Deluge will continue downloading all four files and won't stop until it's fully downloaded all four. The size, % downloaded, ETA details, and such, shown in the main download table, will continue to reflect the entire 2GB torrent. It's as though I'd not made the change. If I toggle the priority back and forth lots of times, then eventually a toggle to skip will result in the size of the torrent changing to 1.5GB, indicating that this time the change has finally fully gone through, and now the % complete, and eta and such reflect only the files not being skipped, and now it'll actually avoid downloading any more of the files marked skip, and stop when the non-skip files have completed.
