You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When resuming downloads, the transfer rate (and accordingly, the remaining time estimate) is calculated incorrectly. For example:
Assume 10MB file.
5MB was previously downloaded.
DL is resumed.
At first, the tx rate is astronomically high and the estimated remaining time shows just a few seconds. It looks like the rate/time calculation is thinking that the first 5MB were downloaded instantaneously.
Suppose it takes 1 minute to DL the next 1MB. Now perhaps the rate would show 102.4KB/s (i.e. 6MB in 1 minute) and estimate less than 1 minute left (to DL the remaining 4MB) when in fact the rate has been 17KB/s (1MB in 1 minute) and it should be 4 minutes remaining.
In other words, I think the calculation is taking into account the previously-downloaded portion, which throws things off. It would be much more helpful if only the size remaining of the file since "resume" were taken into account - then we could have more accurate time (and transfer rate) estimates.
The text was updated successfully, but these errors were encountered:
When resuming downloads, the transfer rate (and accordingly, the remaining time estimate) is calculated incorrectly. For example:
Assume 10MB file.
5MB was previously downloaded.
DL is resumed.
At first, the tx rate is astronomically high and the estimated remaining time shows just a few seconds. It looks like the rate/time calculation is thinking that the first 5MB were downloaded instantaneously.
Suppose it takes 1 minute to DL the next 1MB. Now perhaps the rate would show 102.4KB/s (i.e. 6MB in 1 minute) and estimate less than 1 minute left (to DL the remaining 4MB) when in fact the rate has been 17KB/s (1MB in 1 minute) and it should be 4 minutes remaining.
In other words, I think the calculation is taking into account the previously-downloaded portion, which throws things off. It would be much more helpful if only the size remaining of the file since "resume" were taken into account - then we could have more accurate time (and transfer rate) estimates.
The text was updated successfully, but these errors were encountered: