104539 - Downloading produces incorrect elapsed time and file transfer rate

Status: RESOLVED DUPLICATE of bug 245725

(Core Graveyard :: File Handling, defect)

Description

[[e-mail]]

Download a large file over a slow connection. Pick a file that is downloaded by
clicking on it.  You will first get a window asking you what name to save the
file under, and then when you will click "save" you will get a download window
with a progress bar.

The download time will be calculated starting from the moment the download
window appeared.  The amount of bytes downloaded, however, began while you were
on the filename window.  This results in an inaccurate count.

For instance, imagine that you are actually downloading at a rate of 5K per
second.  You download a 500K file, and you take 18 seconds to pick a filename,
thus downloading 90K.  You get the download window and wait 2 seconds more,
downloading another 10K.  The window will then say that 100K was downloaded in 2
seconds at a rate of 50K per second, and it will claim that 8 more seconds are
left to download the rest of the file.  It has incorrectly used 2 seconds
instead of adding the 2 to the 18.

Comment 1

[Asa Dotzler [:asa]]

-File Handling

Comment 2

[Bill Law]

It looks like the code shows the download dialog, then records the download
start time after the user chooses "save to disk" (meanwhile, data is
downloading).  I think recording the start time first thing will fix this.

Won't get to it tonight, however, so resetting target milestone.

Comment 3

[Boris Zbarsky [:bzbarsky]]

The 0.9.7 ship has sailed....

Comment 4

[Bill Law]

All these download related items are moving out; delayed due to overhaul of 
downloading and many regressions in this area.

Comment 5

[Bill Law]

Spam: Dropping off my list for MachV/mozilla1.0.  If you have issues, please 
make your case by stating which of my mozilla0.9.9 or mozilla1.0 bugs you think 
are of lesser importance.

Please note that *some* of these might be fixed elsewhere if there is work 
being done in the same area of code.  In most of those cases, I will have 
marked such bugs by putting the *real* bug in the "depends on" field.

Comment 6

[Ralph Hartley]

Another, more severe manifestation:

Start downloading a big file, wait until it is almost done, and cancel it (or
let it fail due to outside causes). Start downloading again. At least sometimes
the data from the first try is in a cache and doesn't get downloaded again (this
is Good). The progress bar divides the total downloaded so far by the time of
the current attempt to get the speed.

This causes the time left to be VERY optimistic.

Another example (but in the other direction) is Bug 112336.

I think other browsers have the same problem (I know 4.7 did).

The obvious thing to do, as I see it, is for the progress bar, the first chance
it gets, to record both the starting time (just as it does now) and the
"starting size", how much had been downloaded when the progress bar first starts
looking. To fix 112336, reset them both after a pause.

From that you can calcultate a reasonable speed. If download speed varies, this
will may differ from the "true" average, but at least it has a chance of getting
a reasonable number.

Comment 7

[Ralph Hartley]

I was looking at implementing the fix suggested in my previous comment.

But I could not reproduce this with Build ID: 2002071808. It was always very
obvious before.

Is this fixed?

Some change, not aimed at this bug, might have resulted in the progress meter
getting started sooner. That would at least partially fix this bug (there could
still be issues with downloads that are paused or restarted).

Comment 8

[Michael Hendy (Hendikins)]

*** Bug 163047 has been marked as a duplicate of this bug. ***

Comment 9

[Michael Hendy (Hendikins)]

*** Bug 112336 has been marked as a duplicate of this bug. ***

Comment 10

[Jason M. Abels]

*** Bug 166976 has been marked as a duplicate of this bug. ***

Comment 11

[R.K.Aa.]

dup of bug 81857?

Comment 12

[chAlx]

Shure this is dupe of #81857.

Comment 13

[Ralph Hartley]

This is not a dupe of #81857. That bug is about whether the average speed, or
the "instantanious" speed (whatever that means) is the best thing to display.

This bug is about the average speed being computed incorectly.

Sometime in late 2002 this bug was fixed, with the possible exception of the
case described by #112336 (when the download is paused).

Comment 14

[Adam Kennedy]

Confirm this bug still exists in Firefox production release 1.0.6.

In my case, started downloading a 40 meg video, but left it at the "open or
save" dialog for a few minutes.

Came back and hit "open", when download manager opened it was already 75%
complete, yet it obviously started the count from that point, as it showed a
rate of 10 meg a second and 2 seconds remaining, and the rate decreased with
each refresh while the eta lengthened.

Comment 15

[Steffen Wilberg]

This has been fixed by bug 245725 for toolkit and xpfe. The download start time is now correctly set when the download starts, which is even before the filepicker is shown. And the current speed is calculated by a "smoothed average". It also displays the correct speed after resuming a paused download.
Get Firefox 2 or newer to verify it.