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.
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.
The 0.9.7 ship has sailed....
All these download related items are moving out; delayed due to overhaul of downloading and many regressions in this area.
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.
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.
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).
16 years ago
15 years ago
*** Bug 163047 has been marked as a duplicate of this bug. ***
*** Bug 112336 has been marked as a duplicate of this bug. ***
*** Bug 166976 has been marked as a duplicate of this bug. ***
dup of bug 81857?
Shure this is dupe of #81857.
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).
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.
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.