Progress accounting: negative MB/s at start, finished download stuck at 96%

[eliasbakken]

Found testing v1.1.0-RC8-2-g23a2bb6 on A8 s/n 0498. Two small progress-accounting bugs.

Negative throughput at the start of an operation

[info] DOWNLOADING: -4.66 MB/s (99504448 of 332374256 bytes, 30%)
[info] BACKUPING: -3.38 MB/s (41066496 of 7818182656 bytes, 1%)

Both were the first sample after a previous operation that had got further (a cancelled download at 252 MB, then a finished download at 318 MB). The bandwidth baseline is carried over from the last operation and not reset at start.

Finished download never reaches 100%

The download of rebuild-barebone-v1.1.0-RC8.img.xz finished correctly (file 332 374 256 B, integrity OK), but afterwards:

[info] Download finished in 0 minutes and 37 seconds
[info] DOWNLOADING: 6.71 MB/s (318828544 of 332374256 bytes, 96%)

and get_progress stays at "state":"IDLE","progress":95.92,"bytes_now":318828544. The last size sample is never taken after the download completes. This matters for anything reading STATUS ... PROGRESS (flasher-pi), which sees 95 at the end.

Minor, in the same area: get_progress still logs a progress line while IDLE (IDLE: 0.37 MB/s (235929600 of 314572800 bytes, 75%)), and the JSON carries "File": null.

[eliasbakken]

Fixed in #158 (merged as d611c55), commits 6d0329d and f41f384. resetTransfer clears every counter at each start, so a new transfer no longer inherits the previous one's baseline (the -4.66 MB/s first line). A finished download sets its byte count from the file instead of leaving the last poll's sample at 96%, the bandwidth log is quiet outside a transfer, and the JSON no longer carries "File": null.

Checked on A8 0498: a full download ends at 100% (332374256 of 332374256).