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

[Menard]

I think I ve discovered what goes wrong, and for this, I must ask you : what is the file called .<hash>.parts for each torrent ? For example for one torrent I have one of these files whose size is 200 MB ...

[Menard]

I don't know what to tell you, you are still several versions behind and the problems you seem to have are probably because of a setup you've chosen and not because Deluge is broken.

If it was Deluge, there would be many more reports of this behavior.

Rechecking does the same process that downloading does (SHA-1 check on each piece) and if you just completed the download and it shows 100%, then there is no reason why it would immediately show a different result after downloading. If it does, this is due to libtorrent and not Deluge.

As I've said, you are on outdated libtorrent as well, upgrading could potentially solve your problems. Otherwise I'd venture to say it was your setup or hardware.

But, as you've given us very little except vague details about your setup it's next to impossible for anyone to give you advice. Once again, it's basically "It's not working tell me what's wrong" and no context.

I am on Linux Mint 21.1 with the last kernels for years, now 6.5 version, and what else can be involved ?
I asked you if it is normal that Deluge stores some "parts" of the downloaded data outside the Torrent's folder ? Because that's what I guess it does.
Because it is clear that if we delete these parts, it is clearer that we get what I get.

[Menard]

I had to force recheck all torrents on a repaired partition and the situation is this :
all torrents with more than one file, and even if only one file has been downloaded : all files are incomplete between x% and 99%
What can be significant is the % because the more is allways 99 or 98% and the rest is in decreasing values as 98 97 96 etc you won't have for
example 99% and 75% and if there is one file at 75% you will have something like this : 99% 98% 98% 97% 92% 85% 80% 75%
This seem to me very significant of the cause
For those I checked the md5 sum, the md5 of the incomplete are unchanged compared to their md5 calculated before the force recheck.

In the past I had a similar problem with µTorrent but the files were not really incomplete, and then there was no further download started, but here we see a real download to complete the files.

[Menard]

That's an example

[Menard]

It is weird that nobody found the solution, because it was very simple, I had not this again after I understood that I must not delete these .parts files
I wonder if you even know they exist. (because no return here after I mentionned them)

What in ununderstandable is that torrents store parts of the completed files, in these .parts files, as I I thought that it stored only some unwanted file data, only useful for the swarm.

[mhertz]

Thanks for clearing that up Menard, appreciated

[ambipro]

Just for clarification on the .parts files....this is a libtorrent thing.

When you are not downloading the full torrent, such as selecting only certain files, you are still required to obtain the entire piece (chunk) of data, regardless of if it is a file you want or not....otherwise it is not possible to verify the data you DID download.

Because you do not have a full file, and do not want the full file, that you deselected - libtorrent creates a file for these extra parts and stores the data so the pieces can be verified and seeded.

@Menard It would have been worth mentioning since you were complaining about incomplete torrents, that you had been deleting files from your torrent data. This seems like an obvious thought when you see torrents are incomplete later, and you have deleted stuff in-between the download and recheck.

[mhertz]

Thanks for elaborating ambipro, I needed that too as didn't think of that originally and thought was a quirk somehow lol - forgot piece file-boundary data also in there, which I guess is the thing changing the percentages down of the finished, not seeding torrent(despite deluge stating seeding erroneously, instead finished or 100%, on gtkui here). Hmm maybe if skipped after download started(or from the first/last/prio option bug likewise), then those still saved pieces in parts file possible counts as included also, and hence later missing, not sure and didnt bother check code/documentation, but anyway, thanks

Edit: Deluge uses libtorrent's 'progress' status attribute, a float for percentage complete of current task, here downloading, and as said, libtorrent differentiates between seeding VS finished states based upon if files skipped or not, and lists in api docs download state as having progress meter of files downloaded, so anyway, unless partial pieces existed in said deleted parts file(pieces can cross file-bounderies), then to me sounds like an issue, but can be mistaken/confused obviously. Yes @Menard, only for swarm usage, as ambipro stated, and not for local file relevance in itself, which you yourself also demonstrated through your hashing check before/after rechecking.

Edit2: As even is a part file available, then indeed should be file-boundery pieces available, unless disabling files after began downloading and/or having prioritize-first/last-pieces enabled which is buggy. Anyway, yeah, shouldn't delete such part files if interested in continuing "seeding"(uploading rather, for these), but just for the theoretical and technical side of things, is interesting to discuss.