151810 - Download speed calculated wrong

Status: VERIFIED WORKSFORME

(SeaMonkey :: Download & File Handling, defect)

Description

[Christian Eyrich]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1a) Gecko/20020610
BuildID:    2002061014

If you download a file and it breakes up, you can resume it by just choose the
file for download again and although Mozilla says the partial  saved file gets
overwriten some tmp-file seems to exist (at least in same session and ftp).

Anyway, asume half the file has been downloaded and the resume download starts
there, the download speed is very high at start and decreases fast to a normal
value (I get about 200 KB/s at the beginning and 20 KB/s after about two minutes
- on a max 100 KB/s DSL line!) as the displayed Time Remaining behaves vice versa.
I assume the speed is calculated by transfered Bytes over all diveded by time
elapsed since the resuming download - so you'll get incredibly high values by
dividing e.g. 2 MB by 3 sec.
So it better should be divided by time elapsed including first segment or better
(since you'll don't have this detail) transfered Bytes in this segment by the
time in this segment.

Comment 1

[Kai Lahmann (is there, where MNG is)]

reporter (Christian Eyrich): can you reproduce this bug with a recent build of
mozilla (for example, 1.1beta)? if so, please comment again with details. if
not, please resolve this bug as WORKSFORME. thanks.

Comment 2

[Christian Eyrich]

Yes, I can still reproduce this bug with actual nightlies - also on Win95 (so
assuming it exists on all OS).

Comment 3

[tongro]

This has been a bug for several versions now.

For example, a download is progressing, showing speed of 5k/s and time remaining
of 30 min. Then the download fails, and I restart it. Then the speed is shown as
something like 500 k/s, gradually reducing, and time remaining as 10 sec,
gradually increasing. The first estimate (30 min) is the correct one.

Comment 4

[Erik]

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

Comment 5

[Aaron Kaluszka]

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

Comment 6

[Pham]

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

Comment 7

[Charles Fenwick]

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

Comment 8

[Umbo Dugwue]

also reproduced in recent firebird

Comment 9

[Az]

is this a dupe of 81857 ?

Comment 10

[Jurjen]

The download speed and time left is also incorrect when you spend some time in
the saving dialog. In other words, if you're saving your (new started) download,
there is already downloading going on, but the time elapsed has not started yet.
This results in a wrong speed calculation on the very start of the download. The
speed seems to be calculated with:

speed = (transferred bytes)/(elapsed time)

But the elapsed time does not start on the same moment as the transfer of bytes
starts, results in a wrong speed. Actually the speed is an average speed over
the whole download, I think it should be an average speed over a short period,
which is discussed in bug 81857. It would solve the problem with the speed, not
the time left.

Comment 11

[David Balažic]

The speed calculation is also wrong in stright download ( not resumed ).
Click on file , select destination dir ( during this time the file is already
being downloaded ). The current code calculates speed as
number_of_downloaded_bytes divided by time_since_user_closed_the_file_dialog,
which is wrong, it should be number_of_downloaded_bytes divided by
time_since_download_started.

Using mozila 1.7-RC1 on windows 2000 pro.

Comment 12

[David E. Weekly]

This bug is annoying and is still around in Firefox and Mozilla alike; with a
fast connection, the time spent in the download dialogue, the download speed is
*never* correct on any but the longest downloads. As stated by others this error
affects *all* downloads, not just resumed ones -- the title of the bug should be
updated accordingly.

Comment 13

[David Steiner]

I'm using Mozilla 1.8a3 and the same happens as the others have described above!

Comment 14

[Marc Bejarano]

could somebody with the proper bits update the summary ala comment #12?  it took
me longer than it should have to find this bug because i am experiencing the
issue with normal downloads, not resumed ones.

Comment 15

[Marc Bejarano]

christian?  you listening?

Comment 16

[Marc Bejarano]

oops... sorry for bug-spam :(  i now see that christian DID update the summary
from "Download speed calculated wrong on resumed downloads" to "Download speed
calculated wrong".

d'oh!

Comment 17

[chAlx]

Dup of #81857.

Comment 18

[Marc Bejarano]

chAlx: i disagree that bug 81857 is a dupe.  it is more of an RFE for the UI to
present the current download speed versus the average download speed that it is
now (brokenly) reporting.

Comment 19

[Ryan Jones-Ward [:sciguyryan]]

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

Comment 20

[David Balažic]

The bug hasn't fixed itself...
Firefox 3.0.6/win32

Comment 21

[David Balažic]

This page shows Status: NEW, even if I received an email notification, that it changed to RESOLVED.

Glitch in the matrix ?

On topic: How can I get the fix/verify that the bug is resolved ?

Comment 22

[chAlx]

Attachment: Screenshot: downloading file progress - cancel+retry

Comment 23

[chAlx]

Attachment: Screenshot: downloading file progress - normal start

Comment 24

[Marc Bejarano]

(In reply to comment #21)
> This page shows Status: NEW, even if I received an email notification, that it
> changed to RESOLVED.
> 
> Glitch in the matrix ?

nope.  the email you received likely said:
--
Bug 151810 depends on bug 81857, which changed state.

Bug 81857 Summary: Saving File Dialog "at xx kBit/s" shows overall average speed
https://bugzilla.mozilla.org/show_bug.cgi?id=81857

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |UNCONFIRMED
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

Comment 25

[Robert Kaiser]

Looks correct to me now on the new download manager in SeaMonkey 2.0 Beta 1 and later.