Comment 16 for bug 1450144

On May 29, 2015, at 09:24 PM, Caio Begotti wrote:

>So I couldn't enable the _print() trick but I managed to print it myself
>manually which for this test seems enough. Apparently udm is really
>sending weird download progress stats. See the attached log :-)

Yeah, there are tricks to getting _print() -- really the debug() helper --
working. I forgot to mention that. ;)

>You can see that at [systemimage] May 29 20:51:13 2015 (2055) PROGRESS:
>11853 r 8272 t it decides to go crazy, reporting that it's receiving
>more than the total size (which I thought would be the real final total
>size of files and wouldn't keep changing?). As a matter of fact this
>time the test was slow enough that I could see the progress bar reaching
>100%, then resetting to 0% then going awry with the 'r' stats (for
>receiving) making no sense to me.
>
>The percentages calculated by system-image client seem okay. I mean,
>they are a direct simple calc of these received figures, so of course
>it's going to be wrong...
>
>I'll try to flash a Wily image onto my Arale and see how it behaves, if
>it even behaves differently, but I'd say it's udm's fault... for now.

I concur.

I know that udm downloads the files in a group download sequentially; it
doesn't actually do parallel downloads. I'm not entirely sure how it
calculates its totals; maybe it's doing a HEAD on the various files? At
least, that's how we do it in the si 3.0 built-in curl downloader.

It does seem like udm should at the very least adjust its total if it
downloads more than it originally thought. In any case, I'll add a bug task
for udm and we'll have to let Manuel sort it out.