tr_cpMissingBytesInPiece() can return the wrong value, resulting in invalid availability statistics

[rb07]

Similar to ticket #4204 in respect that the torrent has no seeders, but different in that it shows a nonsense value.

Example:

$ transmission-remote -t 19 -i
NAME
  Id: 19
  Name: <snip>
  Hash: <snip>

TRANSFER
  State: Up & Down
  Location: /opt/var/transmission/downloads
  Percent Done: 3.49%
  ETA: 4 days
  Download Speed: 20.00 KiB/s
  Upload Speed: 0.00 KiB/s
  Have: 126.0 MiB (124.0 MiB verified)
  Availability: 3621%                    <-------------------------
  Total size: 3.52 GiB (3.52 GiB wanted)
  Downloaded: 126.0 MiB
  Uploaded: 96.50 MiB
  Ratio: 0.76
  Corrupt DL: None
  Peers: connected to 3, uploading to 1, downloading from 1

HISTORY
  Date added:       Fri Jul  1 11:39:46 2011
  Date started:     Fri Jul  1 11:39:47 2011
  Latest activity:  Fri Jul  1 13:31:02 2011
  Downloading Time: 1 hour, 53 minutes

ORIGINS
  Date created: Thu Jun 30 22:17:04 2011
  Public torrent: Yes
  Creator: uTorrent/2210
  Piece Count: 902
  Piece Size: 4.00 MiB

LIMITS & BANDWIDTH
  Download Limit: Unlimited
  Upload Limit: Unlimited
  Ratio Limit: Default
  Honors Session Limits: Yes
  Peer limit: 60
  Bandwidth Priority: Normal

$ transmission-remote -t 19 -pi
Address          Flags         Done    Down     Up   Client
x.y.z.w          T?EI          3.5      0.0     0.0  µTorrent 2.2.0
x.y.z.w          UKEH          3.5      0.0     0.0  BitSpirit 3.6.0
x.y.z.w          D?EI          99.9     0.0     0.0  µTorrent 2.2.1

[jordan]

Thanks for reporting this.

This appears to be a regression introduced by r12515 for #4332.

[jordan]

(trunk libT) #4336 "availablility nonsense" -- fix bug in tr_cpMissingBytesInPiece() introduced last week by r12515 for #4332. Add assertions to the nightly build to watch for regressions of this fix.

The bug was that I fixed #4332's off-by-one improperly in tr_cpMissingBlocksInPiece(). The piece's last block is calculated separately because its byte size can be different than the other blocks, The mistake in r12515 was that the last block could be counted twice.

[jordan]

I don't see any path for this bug to cause serious trouble; however, that code is invoked in several places, not just the availability stats. So to be safe I'm promoting from "low" to "high."