Why does this always happen? (99.x% problem)

[Invy]

Ok here's the deal. A few months back I downloaded a torrent from Place A. This torrent contains many smaller RARs in it, as most of you here are likely familiar with. For example, blah.00, blah.01, etc, all the way to blah.60.

Anyway, skip to today, I browse around on Place B and see that this particular torrent needs help seeding on. So I pull this set of files from my archive and copy it over to my hard drive. I load the torrent up and it starts to check the files I have.

This is where the problem starts. It goes all the way to around 99.8% total completed, I check the Files tab in utorrent and see that one of those RARs contained in this torrent was somewhere around 99.7-99.8%. I forget but, let's just put it this way... I had to download 3.72 MB for this particular 2.71 GB torrent to get to 100%.

This is starting to piss me off as it has happened quite a few times now. I made a thread here a few months back but didn't get much intelligent responses. And I know, for a fact, that I have all the files contained in the torrent and that they are all completed fully. I'm also positive that it's not because of a hard drive failing/ RAM related problem, so we can throw that out the window.

Why am I so sure?

1) This torrent has a contained SFV in it. I run the SFV and all the files check out fine with no missing parts. Everything 100%.

2) I extract the file out of the set of RARs without a problem at all. No extraction error in WinRAR or anything like that.

3) Just so you realize, the 2 above phases are done prior to loading it up in utorrent and having to download the missing parts.

4) This happens on both of my machines. Don't say hard drive/RAM problem. We already threw that out the window. My machines run perfectly fine.

5) Relevant to above, i've only seen this problem occur with torrents that have multiple RARs in them.

6) When I look at the Files tab in utorrent, its always one of the "end" files that aren't completed. For example, either blah.00 or blah.60. Or sometimes, it's two adjacent files that are missing pieces. Example again, the "Pieces" column in utorrent shows a bit of white at the END of one file, and then a bit of white at the START of the next file.

7) I know others that have had this happen to them before.

8) And actually on a different occasion, about a week ago, I grabbed a torrent from Place A, then later saw that someone needed some help seeding at Place B. So I started to try and help seed at Place B. Utorrent told me I had about 99.8% after it finished Checking. I then had to download exactly 4.00 MB.

Now here's the part that confirms that it's not a problem on my end - There were also 3 or 4 other people that hopped on to help seed this very popular, particular torrent at the time, and they ALL had to download exactly 4.00 MB! Strange, eh?

Well, damn this took me well over an hour to think and type out. But as you can see, it's definitely not a problem on my end. If you still think so, then you need a cat scan.

Anyway, does anyone have any ideas what could be causing this, or even better, how to solve this? The only thing I can think of is a file system conflict or something. But even that, I dunno. I've always used NTFS, and #8 above really makes me not think that at all. I'm not saying that this is a problem with utorrent or anything like that but it's really getting to be annoying now. If no one else has any ideas, I can go force myself to download the bulky piece of crap (also known as Azureus) just to see if it gives me the same BS.

Thanks in advance

[Nefarious]

so, lets say in this last test of yours where u loaded tracker a and tracker b, if u had the torrent A loaded on utorrent and tried to load torrent B did it just ask if u wanted to add the trackers or was it asking for where to save the torrent, in the first case then it is wierd, if not then probably torrent A and torrent B arent the same even if they have the same files, if torrent A happens to be 4MB pieces and torrent B uses 2MB pieces, the last 4MB piece will be wrong and u'll ahve to get 2MB + the rest of the piece (about 1-2MB should be), then u'll have to get the last piece anyway as it wont be within parameters of the torrent u are trying to help reseed...

thats all i got...

just... are you sure they are the same torrent?

[Invy]

I removed torrent from Place A from the utorrent interface before adding torrent from Place B to it... so your idea is irrelevant. Thanks for the response though.

By the way, I just tried Azureus and it, too, told me I had 99.8% of the file after hashchecking it. So I guess this isn't a utorrent-specific problem like I was beginning to think..

[anoxan]

this happens to me every now and then. I've written it off as an inherent flaw in bt..

I've never found an explanation either.. winrar checks the archives anyway and stops if it's not complete, so yeah...weird O.o

[cam000]

im too lazy to read all that but if the issue u are talking about is it stopping on 99%ish... i had that problem too, but when it got to that i just restarted the program i was using, and then it finished itself off.

[BoundSyco]

Open up each of the torrents, check the hash code and piece size. If the hash codes are differen't and the piece sizes are the same you are lucky you didn't need to download the entire thing, if the piece size's are different then it is as nefarious said.

[armitage]

Perhaps your sfv checker is writing to the sfv file itself when you run it. I know Quicksfv for example does this to flag known good files. This would cause the last pice to fail hash and need re-downloading.

[Invy]

^

I noticed that the Date Modified was changed to the time that I ran it... so you might be right about that. I used QuickPar by the way.

But either way, I can still extract the file out of the RARs without a problem.

I'm beginning to think the same thing that anaxan said about a flaw with bittorrent.

[useruser]

This is not a flaw in bittorrent.

A single bit/byte difference in any file will make the hash of the file different, and therefore all torrent software, not just utorrent, will think of the piece as corrupt/incomplete and therefore need to redownload the entire piece to ensure that the completed download is exactly as specified by the hashes in the torrent file.

This single byte difference can be attributed to an extra space or newline in the .sfv file, (my experience), or even different newline characters caused by the file being opened or even placed on different system types, (also my experience), which can be attributed to the different paths taken to get from the source to the different torrent trackers.

Your rar files are exact copies of the source file, (unless errors occur in transmission between source and trackers), and therefore open fine for each torrent. You must redownload the end/beginning/whatever of the rar files in the same piece as the sfv file because there are no 'inner piece hashes' which can be used to check the individual blocks of a piece.

This is 'short sightedness' of the bittorrent protocol from its original conception to allow piece hashes to span multiple files.

[RestAsured]

[moved to a new topic...since this is a really old topic that probably will get 0 replies anyway]