Original Bittorrent > µTorrent... % complete is less

[gniknomis]

Hi,

I installed µTorrent and got much better download speeds than any other torrent client I have ever used.

However, when I try to add a torrent that I have already started in the original client. The percent complete is considerably less.

Original Client reports: 59.3% Downloaded (after re-check)

µTorrent reports: 36.8% Downloaded

It is big torrent, and that is about 2050Mb difference.

Anyway to improve this? or should I complete this download on the original bittorrent client?

Thanks

[bkman]

It is most likely due to the way that the original Bittorrent client allocates data to files, which is not compatible with the way that utorrent does. Your best bet is probably to finish the file in the original client.

[Huck]

It is most likely due to the way that the original Bittorrent client allocates data to files, which is not compatible with the way that utorrent does.

Never heard of it. Could you provide more information about it?

Thanks.

[Intangir]

I can only postulate as to why this happens, perhaps someone can (in)validate this.

It sounds like you have a *big* torrent, which probably means that there is an abundance of pieces of hefty sizes (like, say, 4MiB each). This could mean that you did not finish completing all your pieces, though you still have essentially downloaded 59.3% of the file in raw MiB/GiBs.

So if you have a few hundred or so unfinished pieces and then you stop a torrent and load it up in another client, it doesn't know that they are unfinished. Perhaps it performs a check on each piece, finds out that all the unfinished pieces fail the check and just discards them. This would essentially remove all unfinished pieces.

And with a ton of partial 4MiB pieces, those MiB can add up quickly. What if you had 300 3MiB partials? 300*3MiB = 900MiB discarded.

[dcorban]

I agree with Intangir, but it does seem kind of unlikely given the huge size difference.

It is also possible that µTorrent doesn't recognize the "out of order" pieces that the Mainline uses.

[gniknomis]

The torrent is 8.9Gb, and has 25 files of ~350Mb and 1 file of ~700Mb.

I'll let BT handle this last download.

[DreadWingKnight]

Intangir has it pretty spot on.

When uTorrent resumed the files, it checked the pieces.

Incomplete pieces (which, for larger torrents are usually larger, 2MiB-4MiB) are discarded because they fail hash check. If you're 1 byte short on the piece, the entire piece is discarded.

This happens regardless of which client you're moving from and regardless of which client you're moving to. There is no workaround.

[bkman]

Intangir is not wrong about incomplete pieces not making the transition between clients, but there are not usually that many incomplete pieces at a time to account for such a large percentage difference. As I said the difference is more likely due to utorrent not understanding the way that the mainline allocates data.

To be more specific, utorrent will look for each given piece at the final location in a file that it is meant to be in, but that is not necessarily where the mainline will place them in the meantime. Quoted from another topic:

The python clients employ a 4th method by default, which is a more-intelligent form of incremental than what Az currently uses: like incremental, file starts out 0-sized, but when piece x comes in, it's appended to the current file position, even if it doesnt truly belong there. As new pieces come in, they are appended and shuffled around as needed: the file size grows only by 1-piece-size for every new piece written, but the pieces are not necessarily/usually in final order.

So you see, without the data that the mainline uses to keep track or which piece is currently where, utorrent can only recognize the pieces that have already been put into their final position, with the temporarily-out-of-order pieces seeming like gibberish. Perhaps there is an intelligent way to overcome this, but it has not been implemented in uttorrent.