Closed Bug 1824618 Opened 3 years ago Closed 3 years ago

Download size is lost after continuing an interrupted download

Categories

(Firefox :: File Handling, defect)

Firefox 113
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: erosman, Unassigned)

Details

Attachments

(1 file)

Attached image download-size.png

Often, a download is interrupted (user pause, connection interruption, server issues etc).
As long as the temp file .part is still present, Firefox will attempt to continue the download.
However, sometimes it looses the target filesize.

Normal: 8 MB of 52.5 MB
Reconnected: 8 MB of unknown

Isnt the target filesize cached?

Type: enhancement → defect
Component: Untriaged → File Handling
Summary: Missing Filesize in File Download Process → Download size is lost after continuing an interrupted download
Version: unspecified → Firefox 113

(In reply to erosman from comment #0)

Often, a download is interrupted (user pause, connection interruption, server issues etc).
As long as the temp file .part is still present, Firefox will attempt to continue the download.
However, sometimes it looses the target filesize.

Could you please provide some additional information?
Which version of Firefox are you using, which operating system, which add-ons (or alternatively just attach a log from about:support), can you post some example of sites/urls where this happens?

Flags: needinfo?(eros_uk)

Ubuntu 22.10 Wayland, Nightly 113.0a1 (2023-03-26) (64-bit)

The issue has been happing for a very long time.
It happens often enough and not on a specific site or a specific file (type), although the larger the file, the more chance of it happening.
The download is initialed directly e.g. clicking a download link/button on a page, or using "Save Video As..." from context-menu.
I have a slow & unreliable internet contention. As a result, I get a few timeouts and/or disruptions during a download.
The screenshot is from https://gofile.io/.
The issue does not happen on each file download (from above site or elsewhere).

When it happens, it occurs when resuming after pause, or refreshing after a failure.

Flags: needinfo?(eros_uk)

(In reply to erosman from comment #0)

Isnt the target filesize cached?

The target filesize may have changed if we resume the download and re-request the same URL later... but also, yes, it is stored in serialized downloads. Here's one I just tried:

{"list":[{"source":{"url":"http://ipv4.download.thinkbroadband.com/512MB.zip","referrerInfo":"BBoSnxDOS9qmDeAnom1e0AAAAAAAAAAAwAAAAAAAAEYBAAAAJ2h0dHBzOi8vd3d3LnRoaW5rYnJvYWRiYW5kLmNvbS9kb3dubG9hZAAAAAgAAAAIAQEAAAAAAQA=","userContextId":0,"browsingContextId":4},"target":{"path":"[removed].zip","partFilePath":"[removed].K3seq1ue.zip.part"},"saver":{"type":"copy","entityID":"%2248400ee5-20000000%22/536870912/Fri, 30 May 2008 14:27:49 GMT"},"startTime":"2023-03-31T15:42:42.083Z","totalBytes":536870912,"hasPartialData":true,"tryToKeepPartialData":true,"contentType":"application/zip","openDownloadsListOnStart":true}]}

(note totalBytes:536870912)

But after reopening Firefox, the download resumed and had a final target size, so I couldn't reproduce.

Looks like Nils implemented some of the resume functionality, perhaps he can comment on where to look for something like this going missing. Given we have no clear steps to reproduce, I expect it's tricky...

Flags: needinfo?(maierman)

With a good internet speed, downloading 512mb, takes a very short time, so the issue might not present itself.

Speed (Mbps)          Downland time (minutes)
------------          -----------------------
 2                    34
 8                     9
16                     4
30                     2

STR (try)

  • If you can throttle your internet speed, you might try that and set a very low speed e.g. 2Mbps
  • Try pause/resume a few times
  • Try disconnecting the internet/Wi-Fi a few times to force a download failure and then refresh/restart the download

Andrei, are you able to reproduce this and obtain http logs of what's happening, perhaps?

Flags: needinfo?(andrei.vaida)

Redirect a needinfo that is pending on an inactive user to the triage owner.
:Gijs, since the bug has recent activity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit auto_nag documentation.

Flags: needinfo?(maierman) → needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(andrei.vaida) → needinfo?(adrian.florinescu)
Flags: needinfo?(gijskruitbosch+bugs)

No luck trying to reproduce the reported issue on Ubuntu 22.04 and Windows 10, with both 113.0b4 and 114.0a1 (2023-04-18) with all the scenarios I could think of:

  • pause/resume
  • crashing Fx while downloading
  • limiting the bandwith
  • various download sources
  • disconnecting/recconecting the network
  • switching from lan to wireless and the other way around.

Please note that the above tests were done on clean profiles, with no addons or any other specific configurations than the default ones. Erosman, could you please confirm that this behavior is reproducible on a clean profile - or please list the addons / about:support here.

The only similar behaviour that I see, but I believe that is the expected one when the connectivity or target host gets cut down and it lists unknown time left, but I don't think it is the same issue.

Flags: needinfo?(adrian.florinescu) → needinfo?(eros_uk)

I will try to find out more. Is there anywhere that I can check some logs?

Pleas note:

  • I have a slow & unreliable internet connection. As a result, it is not feasible to carry out proper testing as downloading a 500mb file takes 30+ minutes.
  • I have to use proxies and therefore some addons, since for example gofile.io is not accessible in my location.
  • I will try to find other example sites. There is another, where I have experienced the issue but sadly most of their files are rather small and with a reasonable net-speed, it will be over before anything happens.
Flags: needinfo?(eros_uk)

If you open about:logging it should be possible from there to get a network log. The problem is such a log may be very large and confusing, if the bug is not easy to reproduce. If you can reproduce frequently enough, then it should be possible to get such a log.

(In reply to Marco Bonardo [:mak] from comment #9)

If you open about:logging it should be possible from there to get a network log. The problem is such a log may be very large and confusing, if the bug is not easy to reproduce. If you can reproduce frequently enough, then it should be possible to get such a log.

+1 on this - some more detailed documentation on https://firefox-source-docs.mozilla.org/networking/http/logging.html if you need it.

Flags: needinfo?(eros_uk)

I will check the log (next time I am downloading) and hopefully it will show something.

Flags: needinfo?(eros_uk)

Logging while downloading file causes the CPU to max and I had to stop it.

We have some suspects about the network, but unfortunately without a log, or repeatable steps to reproduce, we cannot do much to debug the problem.
We'll keep monitoring the situation with interrupted downloads and flaky networks, but we can't proceed further with this specific case.
I'm resolving the bug as incomplete, but if you should ever be able to log a wrongly interrupted download, feel free to reopen with the new information.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: