Re-check Marks Wrong Files as Complete

[Flannelpajamas]

I have found that on re-check, certain files that were downloaded are marked "0.0%" while other, similar named files that were skipped and never downloaded are marked "100.0%".

Version: uTorrent 1.6 build 474

1. The torrent was a 2 DVD set, not compressed, broken into directories DISC1 and DISC2. I had downloaded all of disc 1. (My hard drive is full, and the plan is to share it, then delete files as needed to make room for Disc 2.)

2. I set one of the completed .VOB files to "skip" and closed uTorrent. I deleted this single file.

3. I restarted uTorrent, and forced re-check.

3a. When complete, one of the files in the "Files" tab was marked 99.9%. I have found on the forums that this is natural part of uTorrent, which doesn't care about files, only pieces.

3b. When complete, a set of formerly complete files under DISC1 (VIDEO_TS.BUP, VIDEO_TS.IFO, VTS_01_0.BUP, VTS_01_0.IFO) were marked 0.0%. However, files with the same name under DISC2 were marked complete at 100.0%.

It seems uTorrent REALLY doesn't care about files... but in this case, it's more problematic, I think.

[µtorrent-Guest]

it's not that it does not carewillfully, its more that it has no idea what a file actually is!

All that the protocoll knows and µt handles are pieces.

if you now have lets say your disk 1 with file A it could be that this file is made in part out of piece 4711.

Piece 4711 is also part of file B on disk2, so if you now have deleted the first file those pieces are gone with it while you do the skipping and rechecking in µT. And of course this applies vice versa! (since the files you mentioned are very small, it easily could be that most of them are made out of that one single piece you now have deleted.

so to sum it up: usererror is not a bug

[Flannelpajamas]

I understood that already. I wasn't claiming that aspect as a bug, just a part of how uTorrent works.

It's point 3b that is the problem, from my point of view. If you can explain that, I'd appreciate it.

[µtorrent-Guest]

3b could be the following reason:

I assume here the single piece size is big enough to hold all this tiny ifo and bup files in one pice

both disks ifo's and bup's were in a piece that was part of the vob you in the end have deleted.

once you set this vob to skip in µt those 1 piece that holds the other ifo/bup files and a part of this vob will enter this status where this piece is saved in the "partfile" you can see in the filesdirectory in case this option is set in advanced settings and you skip some files.

since you told µT upon restart to download now those ifo/bup for disk2 he assigned fromarly into this partfile he takes those data out if it, writes it to the files for disk 2 and leave the rest in it.

those rest of this partfile piece for the deleted vob from disk 1 is gets deleted when you close µT.

it's just a speculation since I don't know how the internals of µt work: probably while rechecking µT first came to the point in the stream piece where the deleted vob was, discarded the data at that point so it could'nt find the rest of the "free flowing pieces" for the disk 1 ifo/bup anymore. It did find the disk2 ones because they were written to the corresponding files from this partfile in the moment you told µt to download this "files"

giving my believe how µt handles this situations with partfiles, the explaination why you see some files as 100% and some as 0% seems logic.

Of course if the programmer could explain in details how µt handles the big -unaware of seperate files- datastream, the behaviour you mentioned could show that there is a bug, until then it makes sense to believe its normal. So I guess the thing to remember is; do not delete a file if this file shares pieces with other files in the torrent until µt has downloaded the whole stream and could assign every part of every piece completely to its corosponding file.

(you might want to try to not use "partfile", maybe µt then does not "borrow back" those shared pieces from multiple files if you delete one of those files that share parts of the piece)

[Ultima]

However, files with the same name under DISC2 were marked complete at 100.0%.

Filenames are entirely irrelevant, so I'm not sure what you're getting at here. As you already know, there is no concept of files. If a piece is shared by multiple files, and at least one part of that piece is missing, the entire piece gets junked. As µtorrent-Guest said (a bit long-windedly), if a file is small enough to fit in a single piece, and the piece is junked because of a missing part, would it not be logical that the file is marked as being 0% complete?

[Flannelpajamas]

Yes, Ultima, I can see why the file would be marked as 0% complete (though my understanding of how uTorrent works isn't terribly deep).

But I didn't understand why a different file with the same name which was not listed as downloaded before would then be marked as 100% complete. Seems like a switcheroo.

See, I was worried that some file information (disk2/VIDEO_TS.BUP) might get written to the wrong place (disk1/VIDEO_TS.BUP), or vice versa, but uTorrent-Guest's explanation suggests this isn't the case.

His hypothesis makes sense to me (I'm not sure I understood it completely, and it assumes I started on disk2, which I hadn't yet, but it mostly worked for me).

[Flannelpajamas]

Here's an update: I started to redownload the deleted .VOB, out of curiosity. The files switched back again! That is, DISK1/VIDEO_TS.BUP now reads 100% complete, and DISK2/VIDEO_TS.BUP reads 0% complete.

The ONLY change I made was to set the deleted .VOB to Normal download.