Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2299 closed Bug (invalid)

transmission daemon reports slightly incorrect percent done at the times

Reported by: umet Owned by:
Priority: Normal Milestone: None Set
Component: Daemon Version: 1.72
Severity: Normal Keywords:
Cc:

Description

When downloading sometimes the percent done as reported by transmission daemon is sometimes a bit of to the higher value (like 53% versus true 50% reported by the peers or by calculating by hand using the pieces downloaded).

Verifying the torrent does not help. However, removing the resume file does fix the situation and the correct percentage is reported.

I doubt this is really daemon related, but that is all that I use.

Change History (9)

comment:1 Changed 12 years ago by charles

Could you give a concrete example of this?

comment:2 Changed 12 years ago by umet

I have one torrent downloading, total size of 26.3GB (6723 pieces of size 4194304)

Percent done reports 63.9%, all other peers report 61.9%. Transmission daemon reports that I have 16.8GB, of which 16.2GB is verified. Now, the 63.9% matches the downloaded size, whereas 61.9% matches the verified size.

However, if I count the ones in pieces list, I do get 16.2GB or 61.9%. If I stop the transmission and remove the resume file to start from scratch, after verifying the downloaded data transmission is back on track that I have 16.2GB.

The 0.5GB difference seems to be the problem here. I wonder where it comes from?

This is a bit hard to reproduce, but it is observable with big torrents and slow seeder situations. This is not the first time I have seen this.

comment:3 Changed 12 years ago by charles

Where are you seeing this number? Is it in the raw RPC response given back from the daemon? If you're using either the remote /or/ the web ui, could you try using the other and see if the numbers are the same? If you're using remote, could you add the "--debug" argument so that we can see what the daemon's RPC-level response is?

comment:4 Changed 12 years ago by charles

Also, does this problem persist in 1.73?

comment:5 Changed 12 years ago by umet

The numbers are from remote -i output, and the web ui reports the same percent done and size as remote.

From --debug output I can see that downloadedEver value matches the have size and haveValid matches the verified size. However, haveUncheked is more than the difference of the two, i.e., haveValid + haveUnchecked is about 1MB more than downloadedEver. It is not just the remote/web ui issue. I was notified by someone else of this odd reporting, so it must be part of the tracker/peer communication as well.

I haven't tried 1.73 yet.

comment:6 Changed 12 years ago by umet

Or come to think of it, I don't think downloadedEver is used for reporting, but it is just so close to haveUnchecked + haveValid that I just thought that first.

comment:7 Changed 12 years ago by umet

I updated to 1.73 and it is the same. After verifying torrent the numbers are the same, and the sum of have numbers is still greater than downloadedEver.

comment:8 Changed 12 years ago by charles

  • Resolution set to invalid
  • Status changed from new to closed

The more I look over this ticket, the more I think this is not a bug or incorrect behavior at all.

I have one torrent downloading, total size of 26.3GB (6723 pieces of size 4194304)

Percent done reports 63.9%, all other peers report 61.9%. Transmission daemon reports that I have 16.8GB, of which 16.2GB is verified. Now, the 63.9% matches the downloaded size, whereas 61.9% matches the verified size.

The other peers are very likely to have more than 61.9% overall but, since you can't checksum an incomplete piece, peers don't advertise incomplete pieces. The 61.9% is the subset of that which is actually complete and verified.

Your own situation is the same: you have 61.9% that's complete and checksum-verified correct. You also have an additional 2% of various incomplete pieces.

However, if I count the ones in pieces list, I do get 16.2GB or 61.9%.

That's because you only get 1s if the piece is complete. The extra 2% is in incomplete pieces.

If I stop the transmission and remove the resume file to start from scratch, after verifying the downloaded data transmission is back on track that I have 16.2GB.

That's because when you delete the resume file, Transmission doesn't know which incomplete pieces it has anymore, and can only verify complete pieces. This causes you to lose the extra 2% and drops you back down to 61.9%.

The 0.5GB difference seems to be the problem here. I wonder where it comes from?

From incomplete pieces.

comment:9 Changed 12 years ago by umet

You are right, I think it is just different reporting compared to other clients. Towards the end the incomplete piece count goes to zero and at the end the everything is correct. With big torrent the difference is just surprisingly big at the middle of the download.

Note: See TracTickets for help on using tickets.