"Completed" torrents incomplete upon "Force Re-check"

[user1123]

I've noticed that about 25% of my completed torrent files were giving me some issues. So I did the following:

1. used 'ls -l' to check the size of the 8 files in the torrent
2. did an 'md5sum' on those 8 files.
3. "Force Re-check" the torrent. After the re-check completed, deluge now showed files 1 and 2 at 99% (the other 6 files at 100%).
4. I started the torrent and it 'completed' again.
5. After they completed for the second time, I ran 'ls -l' and the file sizes were identical to the first time I ran the command on the incomplete 'completed' files.
6. I then ran md5sum on the files and file 3 through 8 had an identical md5sum, but files 1 and 2 had new md5sum.

I've attached a screenshot right after the "Force Re-check" completed, showing that the torrent was already complete, but is now at 99.96%. This torrent was successfully moved the my 'completed torrents' directory, as expected on successful completion.

md5sum when torrent was showing "Seeding" and at 100% (complete):

Code: Select all

0a573107cf1af2310bbece212519ae7b  /mnt/user/Downloads/[REDACTED]v  
a30c0d5f44a30f512bf623aad5fd333c  /mnt/user/Downloads/[REDACTED]v  
17f5f899365e8a83c724df347ce6f53a  /mnt/user/Downloads/[REDACTED]v  
012c1e0fd13caf887f4e3a1d7e7c0e8d  /mnt/user/Downloads/[REDACTED]v  
e1dd6c50d4df6d38de0e20a5bb3430f1  /mnt/user/Downloads/[REDACTED]v  
cd32614dd75b0f0f4494f7a2cf880555  /mnt/user/Downloads/[REDACTED]v  
1158d333a6776d6afb84eef90e0aa657  /mnt/user/Downloads/[REDACTED]v  
bd0fedcf337e3d9be2641340e40a2884  /mnt/user/Downloads/[REDACTED]v 

md5sum after "Force Re-check", then "start" then re-completed:

Code: Select all

bba751985e21c7ed573cb5fbdbc0b723  /mnt/user/Downloads/[REDACTED]v  
d0a2fb4d41ee6862fb4ae0044b08af09  /mnt/user/Downloads/[REDACTED]v  
17f5f899365e8a83c724df347ce6f53a  /mnt/user/Downloads/[REDACTED]v  
012c1e0fd13caf887f4e3a1d7e7c0e8d  /mnt/user/Downloads/[REDACTED]v  
e1dd6c50d4df6d38de0e20a5bb3430f1  /mnt/user/Downloads/[REDACTED]v  
cd32614dd75b0f0f4494f7a2cf880555  /mnt/user/Downloads/[REDACTED]v  
1158d333a6776d6afb84eef90e0aa657  /mnt/user/Downloads/[REDACTED]v  
bd0fedcf337e3d9be2641340e40a2884  /mnt/user/Downloads/[REDACTED]v 

Perhaps unrelated, but I've noticed that sometimes, a torrent will show "Seeding" or "Queued" and also show a "Completed" date, but will not have been moved the my "completed" directory. Sometimes a "Force Re-check" will show these as complete, other times they will also have the issue that I described above (but there doesn't seem to be any pattern/relation).

[Shryp]

This can happen with media files if your audio / video players are changing the meta data or the tags associated with the files.

[Menard]

This can happen with media files if your audio / video players are changing the meta data or the tags associated with the files.

I think that it is not the problem because I personnaly had this with zip files as well, and so no application is changing something in them, I didn't unzip these files before to recheck them, it is the same for the videos, 90% of the time I back them up before to open them in a video player, and I recheck them before backing them up

I guess the problem is preallocation of the files, that make files have the right hash even when 0 data in them ... (check this possibility, I personnaly didn't at that time

[Menard]

I've noticed that about 25% of my completed torrent files were giving me some issues. So I did the following:

For me it is higher as around 100% of my torrents which contains more than one video and 0% for those with one unique video

This morning I rechecked 3 completed torrents

1 - 4 files : 98% 99% 99% 97%
2 - 1 file : 99%
3 - 2 files : 99% 99%


What is more weird is that after completed, they really need to download additional data to be completed again ... I see this because it must wait for a connected seeder and then a download appears

So how is this possible, as the hash doesn't change but data are downloaded in between

[ambipro]

md5sum when torrent was showing "Seeding" and at 100% (complete):

Code: Select all

0a573107cf1af2310bbece212519ae7b  /mnt/user/Downloads/[REDACTED]v  
a30c0d5f44a30f512bf623aad5fd333c  /mnt/user/Downloads/[REDACTED]v  
17f5f899365e8a83c724df347ce6f53a  /mnt/user/Downloads/[REDACTED]v  
012c1e0fd13caf887f4e3a1d7e7c0e8d  /mnt/user/Downloads/[REDACTED]v  
e1dd6c50d4df6d38de0e20a5bb3430f1  /mnt/user/Downloads/[REDACTED]v  
cd32614dd75b0f0f4494f7a2cf880555  /mnt/user/Downloads/[REDACTED]v  
1158d333a6776d6afb84eef90e0aa657  /mnt/user/Downloads/[REDACTED]v  
bd0fedcf337e3d9be2641340e40a2884  /mnt/user/Downloads/[REDACTED]v 

md5sum after "Force Re-check", then "start" then re-completed:

Code: Select all

bba751985e21c7ed573cb5fbdbc0b723  /mnt/user/Downloads/[REDACTED]v  
d0a2fb4d41ee6862fb4ae0044b08af09  /mnt/user/Downloads/[REDACTED]v  
17f5f899365e8a83c724df347ce6f53a  /mnt/user/Downloads/[REDACTED]v  
012c1e0fd13caf887f4e3a1d7e7c0e8d  /mnt/user/Downloads/[REDACTED]v  
e1dd6c50d4df6d38de0e20a5bb3430f1  /mnt/user/Downloads/[REDACTED]v  
cd32614dd75b0f0f4494f7a2cf880555  /mnt/user/Downloads/[REDACTED]v  
1158d333a6776d6afb84eef90e0aa657  /mnt/user/Downloads/[REDACTED]v  
bd0fedcf337e3d9be2641340e40a2884  /mnt/user/Downloads/[REDACTED]v 

Perhaps unrelated, but I've noticed that sometimes, a torrent will show "Seeding" or "Queued" and also show a "Completed" date, but will not have been moved the my "completed" directory. Sometimes a "Force Re-check" will show these as complete, other times they will also have the issue that I described above (but there doesn't seem to be any pattern/relation).

While some of these files are identical based on MD5, not all are identical, the first two are not present anywhere in the bottom block.

Perhaps during moving you experienced corruption, I'm not sure, but if the files were moved to a NAS, to a drive experiencing SMART errors, or having any file system issues (chkdsk/fsck or something may remedy this) then that may explain the symptoms you're seeing.

You can try and recreate/verify this by copying a large file (~8-10GB) in the same manner deluge would from your download directory to your completed directory manually, and checksumming it, I would also check for SMART health errors, particularly CRC, and run a chkdsk or fsck-type command on your source AND destination drive just for sanity's sake.

Files may also become corrupted from hard-shutdowns due to power loss or seg-faults/crashes in deluge during read or writing to that file, so it's entirely possible this happens organically just over time and unlucky circumstances. The fact that you are experiencing it more often (I assume) leads me to believe it is more likely one of the other issues, or something I did not mention.

[ambipro]

I've noticed that about 25% of my completed torrent files were giving me some issues. So I did the following:

For me it is higher as around 100% of my torrents which contains more than one video and 0% for those with one unique video

This morning I rechecked 3 completed torrents

1 - 4 files : 98% 99% 99% 97%
2 - 1 file : 99%
3 - 2 files : 99% 99%


What is more weird is that after completed, they really need to download additional data to be completed again ... I see this because it must wait for a connected seeder and then a download appears

So how is this possible, as the hash doesn't change but data are downloaded in between :o

My understanding of preallocation is that it essentially occupies the sectors/space on your drive with what are essentially "zeros" before writing, signifying to the OS and file system that that space is occupied. It should have no effect on the data after initial allocation and the data post-completion would not be affected by this option. It is merely something to help with running out of space mid-download or optimize what would otherwise be non-sequential writes to disk in the event of a slower download.

If you see my previous post, I make some recommendations, but there are multiple other factors in the majority of people's torrenting setups that could potentially contribute to these symptoms, particularly with video and audio files. If you use plex or jellyfin directly with your seed files, or some other media server, as mentioned before, or have scripts running to extract data/move files, or perhaps radarr/sonarr's root directory setup improperly, all of these could lead to your original seed data becoming modified or "corrupted"...the .zip file's are rather curious, and lead me to believe it is possibly a drive/file system issue, but that could also be from bad luck or a crash/hard-shutdown and not an overall symptom of this larger issue - just a coincidence.

I, personally, would need a much larger amount of information to narrow things down if none of this helps, unfortunately....because the sample size and environmental data are both extremely limited and none of this is reproducible :(

[ambipro]

To @Menard and @user1123

I was PM'ing with @mhertz and discussing this post, and a few specifics came up.

If you could each provide us with a few details that we are both sort of unclear on or were not given...that may help - or may not. But will give a better chance.

1. Deluge version and libtorrent version (available in help -> about)
2. Operating System and version (Windows version or for linux give distro and paste from 'uname -a')
2. If you're downloading directly to a folder or moving it upon completion, and if so is that completion directory local or remote/NAS/etc
3. Do you use any software that would directly access the seeding files other than deluge (include via hardlinks) such as plex, radarr, sonarr, jellyfin, emby, etc...
4. Are these public or private torrents, and have you found this to be reproducible with any sort of consistency across separate trackers?
5. Were the torrents INITIALLY/ORIGINALLY downloaded to 100% and seeding for a time, and later changed status to "ERROR" and upon recheck incomplete (less than 100%) or did they stall/stop at less than 100% and required rechecking to complete. This was not clear to us.
6. After going through recheck and getting them 100% and competing/seeding status, did this ever occur AGAIN and require the same recheck AGAIN on a torrent?

Any other information you might find relevant, please include.

[Menard]

First I remember having read about such problem in a old time as around 2008 with µTorrent and it was considered by specialists as a problem with file system organisation and files, perhaps with defragmentation or something like this, but as something as an artefact, not an issue for neither the system nor the bittorrent nor applications but I don't remember more precisely, because I had a gap with torrenting after this (because I became salsa man)
It seems to me that the constance of this phenomenon, make the role of the environnement or hardware not possible, I personnaly didn't move the files, only for few of them, I check my hard disks very often, SMART one time a week, checkdisk too and my system doesn't generate errors , even at hard shutdowns generally, it can happen sometimes I find some minor errors

Deluge 1.0.3 libtorrent 1.1.13.0 Linux Mint 20.3
Directly on a hardisk but mostly an external USB HD (Often when I copy files from or to it, I check the hash of both files or folders and I get no mismatch)
I use Nemo as file explorer and so it can sometimes access the download folders
Private torrents generally, not possible to answer because I use one unique tracker now
(5) it is clearly allways in the first case you described (after a long seeding time)
(6) Difficult to know because I d have to take notes each time (which torrent and when) it is perhaps to do

[ambipro]

Deluge 1.0.3 libtorrent 1.1.13.0 Linux Mint 20.3

You know we are on 2.1.1 now, and libtorrent is on 1.2.x and even has a 2.0.x branch that Deluge supports...

I'm kind of hoping you typo'd and it's supposed to be 2.0.3, because 1.0.3 is crazy old...I mean I've seen people sticking with 1.3.5 or whatever, but 1.0.3 (1.1.13.0) is deprecated as hell. It wouldn't surprise me in the least if you came up to the current version (or at least 1.3.5) and a current version of libtorrent if these issues went away.

If it is 2.0.3 and not 1.0.3, I would still recommend updating to 1.2.x of libtorrent, as a lot of protocol and improvements were made, or if you are feeling froggy you can go to 2.0.8....1.1.13 is from like 2018-19...

[mhertz]

Sorry I have no input really, but appreciate ambipro being always helpfull and knowledgable as per usual, thanks Also thanks for referencing me After talking to him about this in private, I think he's right in that it's probably an USB drive corruption issue, but I still just don't get why not listed anyway by deluge/libtorrent, as the hash check should fail and not list seeding/finished??? Also the non 100% download files while seeding is very puzzling to me - granted this calculation is done by libtorrent in an "as precise as possible" way as per listed in api docs(torrent handle / file_progress() ), but still - and I understand it's not fully accurate during download, where just returns a list with floats for every file which deluge multiplies by 100 to show under files tab, but when libtorrent returns 1.0 for each, then should mean finished, and so no reason to show e.g. 0.9999999. Also it lists the default calculation libtorrent uses as most precise and costly, and which deluge uses, but the other method libtorrent supports states to take into account only finished downloaded pieces clearing hash check(and cheaper to "calculate", as know it already so don't need calculate), so sounds little backwards, but i digress. Hmm, it might clear the hash check, but that is in memory, and so when writing to disc, especially cheap USB drives, then maybe has bad blocks, but still, libtorrent returns progress of pieces downloaded i.e. in memory and not regarding filesystem event, well unless i'm mistaken, i'm not sure at all upon any of this honestly...

Anyway, as seemingly a viable workaround is to force-recheck on problematic files, at-least for most part if I didn't misunderstood(mentioned here and elsewhere as workaround), then atleast for time being, I whipped up a quick plugin to hopefully workaround this issue until further troubleshooted fully. It just hooks into torrent finished event and checks every file in it for if 100% downloaded, and if not then runs a recheck - normally this is futile I know, as shouldn't be possible, but yet seemingly is as per this thread, and others i've seen. Anyway, if the torrent finished event isn't even sent, then I added an alternative less effecient method, just looping every x minutes over all torrents loaded and does the same check on the seeding ones - this alternative mode can be enabled with changing the 'interval' option from default 0(meaning alternative mode disabled), to whatever else number(in minutes). Support for said interval setting is in gtk-UI, webUI and config-file.

Hope helps slight little bit meanwhile. Thanks again ambipro.

workaround-0.1.egg