If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

estimated time and download speed stop reporting when download speed is zero

NEW
Unassigned

Status

()

Toolkit
Downloads API
10 years ago
3 days ago

People

(Reporter: The Trystero, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0

Sometimes the speed of the download falls to zero, as properly indicated by the Download Statusbar Add-On. However, on the Download Manager, the speed indicates the last non-zero speed. If one does not have the D-Statusbar addon installed, or is looking only at the Download Manager, you would not know that your download has stalled.

Reproducible: Always

Steps to Reproduce:
1. As a proxy, install Download Statusbar Addon:
https://addons.mozilla.org/en-US/firefox/addon/26
2. Restart Firefox
3. Download a reasonably large file
4. When progress is halfway through and clearly still active, unplug ethernet/turn off wireless/turn off modem
5. Observe that progress indicator on FF Download Manager stops, but indicates a non-zero speed. Download Statusbar indicates zero speed as expected.

Actual Results:  
Download Manager indicated non-zero speed in middle of file download when there is no internet connection.

Expected Results:  
Speed indicator should be zero.

Updated

10 years ago
Duplicate of this bug: 435381
(Assignee)

Updated

9 years ago
Product: Firefox → Toolkit
Duplicate of this bug: 462747
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: Macintosh → All
Summary: Inaccurate download speed indicator → Inaccurate download speed indicator if download speed is zero

Comment 3

8 years ago
Firefox 3.6 still can be stalled with the lastest download speed instead to show a null activity.
After a while, the user must be warned a download has stalled. More, some websites didn't allow a resume, so it must important to warn him.

Updated

7 years ago
Blocks: 565517
No longer blocks: 565517
Duplicate of this bug: 807084

Comment 5

5 years ago
When hang, download speed is Totally incorrect, as bug 807084 says.

This bug is from 2008 and still nobody bothered to fix it. "inaccurate" sounds like a small problem, but it is not the case.

The title of The bug is misleading. "inaccurate" should be replaced with "totally incorrect".

Comment 6

5 years ago
There's two related situations here:

1) If the download fully stalls it continues to report the last known speed and time estimate indefinitely, thus giving no indication that it has stalled.

2) If the download stalls intermittently it only reports a speed when it has one, thus giving a higher than true speed and an underestimated time to completion.

I've seen way too many downloads with more stall time than download time and the result is a bogus download speed and an estimated remaining time that is wildly shorter than it's really going to take.
Summary: Inaccurate download speed indicator if download speed is zero → estimated time and download speed stop reporting when download speed is zero

Updated

3 years ago
Duplicate of this bug: 1050355

Comment 8

3 years ago
(In reply to Dave Garrett from comment #6)
> 2) If the download stalls intermittently it only reports a speed when it has
> one, thus giving a higher than true speed and an underestimated time to
> completion.

That's the case with Uploaded.net / Ul.to, a rather popular file host. To test, download any large file without logging in.

Updated

3 years ago
Duplicate of this bug: 881182

Comment 10

4 months ago
(In reply to :Paolo Amadini from bug 1281668, comment 1)
> We use a simple algorithm to calculate the download speed and it may definitely have
> some limitations like the one you described. [...] if you have any example of other
> programs or algorithms doing a better job in the case you described, we might
> definitely investigate and adopt them.

Opera 45.0.2552.888 doesn't have this problem (I don't know whether it's something they developed on their own or inherited from Chrome). Though Opera never shows a speed of 0 bytes/s on the Downloads panel, on the Downloads details tab it flips back and forth between 0 bytes/s and non-zero bursts.

Another example I've come across is Uploadgig.com.

Comment 11

3 months ago
A nice, open source example should be available in 'scp' (secure copy, part of 'ssh' I believe). 

It shows percentage and kB downloaded, download speed, and ETA. Download speed updates about twice each second. 

Download speed tapers to 0 if the transfer is held, and reaches 0 after about 5 seconds. This makes me suspect that it simply maintains a record of the last 10 measurements (at 2/second), and shows the average of those values.

Comment 12

3 days ago
Firefox currently uses exponential smoothing which is a very good strategy, but two changes need to be made:

1) To handle stuck downloads, DS_setProgressBytes should be called periodically, even when there is no new data. It could be called at a fixed interval, or with exponentially increasing intervals to save battery life. The interval should be reset to a small value whenever new data is received.

2) To handle bursty downloads, the smoothing factor must take the length of the update interval into account so that the smoothing time constant remains constant. In DownloadCore.jsm, change

    this.speed = rawSpeed * 0.1 + this.speed * 0.9;

into

    let k = Math.pow(0.9, intervalMs / kProgressUpdateIntervalMs);
    this.speed = rawSpeed * (1-k) + this.speed * k;

The algorithm is duplicated in urlbarBindings.xml, so do the same thing there.
You need to log in before you can comment on or make changes to this bug.