Downloading produces incorrect elapsed time and file transfer rate

RESOLVED DUPLICATE of bug 245725

Status

Core Graveyard
File Handling
RESOLVED DUPLICATE of bug 245725
16 years ago
2 years ago

People

(Reporter: arromdee2@yahoo.com, Assigned: Bill Law)

Tracking

({helpwanted})

Trunk
Future
x86
All
helpwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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

16 years ago
-File Handling
Assignee: asa → law
Component: Browser-General → File Handling
QA Contact: doronr → sairuh
(Assignee)

Updated

16 years ago
Target Milestone: --- → mozilla0.9.6
(Assignee)

Comment 2

16 years ago
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.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
The 0.9.7 ship has sailed....
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8
(Assignee)

Comment 4

16 years ago
All these download related items are moving out; delayed due to overhaul of 
downloading and many regressions in this area.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
(Assignee)

Comment 5

16 years ago
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.
Keywords: helpwanted
Target Milestone: mozilla0.9.9 → Future

Comment 6

16 years ago
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

16 years ago
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).
Blocks: 166976
QA Contact: sairuh → petersen
Blocks: 173662
*** Bug 163047 has been marked as a duplicate of this bug. ***
*** Bug 112336 has been marked as a duplicate of this bug. ***

Comment 10

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

Comment 11

14 years ago
dup of bug 81857?

Comment 12

13 years ago
Shure this is dupe of #81857.

Comment 13

13 years ago
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

13 years ago
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.


Updated

11 years ago
Blocks: 372972

Comment 15

11 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 245725

Updated

11 years ago
No longer blocks: 372972
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.