Deluge 1.2.1 stats wrong

[Ibslice]

Deluge 1.2.1 download stats are still slightly off compared to all other clients. (except for a 1 off of transmission)

example:

[loki]

I see your point but that's less than 1% error, even the transmission one is within 1% error.
I would be interested to see at least one more example possibly with more results from the seed list, and to see what the developers say next...

[Ibslice]

Yeah I agree it is only 1% and obviously not worth banning a client over - but the thing is - why does it do it and a client like utorrent or bittornado or rtorrent or ktorrent or halite not do it?

Deluge is not the only client that does this. Azureus/Vuze, Transmission and Deluge and uTorrent 1.7.7 (the 1 build only) do it - but NO others. I checked the swarms on 500 torrents.

[johnnyg]

Is that the value reported by Deluge or is that value calculated by the tracker?

[charles]

uTorrent volunteer Firon has summarized what's going on in download stats:

&downloaded= was changed at some point by Azureus to only include completed, valid data. They then added the &corrupted= field to contain the rest of the 'missing' data that wasn't included in downloaded anymore.

uTorrent then followed suit later. I think it's a good idea since the only meaningful data downloaded is completed pieces.

It basically is reporting only complete pieces, but it's pieces completed since the last start event, so it can be less than filesize when you complete or even just 0 in future sessions.

It wouldn't be a bad idea to update the spec to add &corrupted= officially and change downloaded to mean only valid data.

Transmission adopted this behavior in version 1.90.

I thought that Hydri had done the same in the version of libtorrent-rb required by Deluge 1.2.1 though, so I'm not sure what's going on there.

[loki]

Is that the value reported by Deluge or is that value calculated by the tracker?

These specific values are from the tracker.

[johnnyg]

I thought that Hydri had done the same in the version of libtorrent-rb required by Deluge 1.2.1 though, so I'm not sure what's going on there.

Yes he did, hence why I was asking if that was the reported value.

[MusicalMind]

Well, that is a lot of nonsense that the tracker is to blame. If the tracker was to blame, then all clients would have the same error, and they do not.

Further, Halite-3.2.2 produces the same error margin as Deluge 1.2.1 does. Tested on three different trackers with exactly the same error margin. By that I mean the report to the tracker from both was identical. I did it with only one seeder to one peer to make sure there was no overlap of data.

To me personally, less than 1% is entirely acceptable, but the error certainly does exist.

[chrisbeebops]

I thought that Hydri had done the same in the version of libtorrent-rb required by Deluge 1.2.1 though, so I'm not sure what's going on there.

I thought he did too....

&downloaded= is now defined as to exclude failed and redundant bytes, bringing it in line with the behavior of other major clients.

If that is true, Deluge (really, clients based off libtorrent-rb >= 0.14.9.0) should report back exactly the size of the torrent when the download is completed. While an error of <1% is likely acceptable at most private trackers, it is an error nonetheless and should be fixed.

[trektorrents]

The error is in Deluge 1.2.1, Halite 0.3.2.2, Transmission (most versions) and Azureus/Vuze (the older the less the error.)

uTorrent, rTorrent (rakshasa) and BitTornado all report the exact file size.

Peer list after peer list on dozens of different files note this.