Closed Gregor1996 closed 3 weeks ago
Changing the downloader to the WinINet APIs required a full reboot. This was visible from the reduced download speed (aproxx. 17.1 Mb/s) after the switch. But on this second machine, a Surface Laptop 6 for Business, does not help while it completely fixed the problem on my Dell Inspiron 5505
Changing the downloader to the WinINet APIs required a full reboot. This was visible from the reduced download speed (aproxx. 17.1 Mb/s) after the switch. But on this second machine, a Surface Laptop 6 for Business, does not help while it completely fixed the problem on my Dell Inspiron 5505
I'm not understanding why it would need a full reboot; Can you share how you changed the downloader?
I'm not understanding why it would need a full reboot; Can you share how you changed the downloader?
It was probably my fault, I moved the documentation link comment at the beginning of the file, before the braces. Anyways, on this device even the WinINet APIs downloader does not work, on the Dell it did not require a full reboot to start working after I changed to the WinINet APIs downloader.
Anyways I will attach the new settings file.
This is a screenshot clearly displaying the timeout problem, this is on the above mentioned Surface with WinINet APIs as a downloader
The Delivery Optimization downloader works with my Hotspot Mobile connection
I have an update. It is now not working even on my Dell with WinINet APIs downloader.
Guys this issue is getting worse and worse. I'm the only one having this issue? Can anybody reproduce the same issue? This issue needs attention!!
In general, we're not getting many reports of slow downloads since the download is coming from the publisher's URL for the package, and there isn't much we can do about that.
From the WinGet side of things, do you see the same kind of download performance issues if you use the "Download" command?
winget download <package id>
- The installer and manifest would land in the Downloads directory by default.
In general, we're not getting many reports of slow downloads since the download is coming from the publisher's URL for the package, and there isn't much we can do about that.
From the WinGet side of things, do you see the same kind of download performance issues if you use the "Download" command?
winget download <package id>
- The installer and manifest would land in the Downloads directory by default.
I never talked about a performance issue, I would be okay if the download took 1 hour. The issue I talked about is the download freezing before completion, consistently, 100 % of the time, with large downloads.
In fact I get exactly the same behaviour from the "Download" command, the download freezes and does not recover, the only thing that can be done is cancel the download.
Additionally the package I'm experiencing the issue with is hosted on GitHub, and have the same download speed of all the Microsoft packages hosted on there.
At last I've searched the web for this issue and did not find any other post talking about this. For this reason I've held from reporting it a year ago when I've first experienced it on my Dell, and I'm reporting this issue now that I've verified it on a second device, and now that the fix I've found for my Dell, using the WInINet's API instead of the standard Delivery Optimization, stopped working
I have additional findings.
The download timeout is set exactly at 5 minutes, even if I partially disconnect my device from the network it still times out after 5 minutes.
Can you guys look into that? Is this a Winget timeout or is it a GitHub timeout? If it is a GitHub timeout where should I report the issue?
Can someone look at this??
I think it is a DO timeout issue because when I used the WinINet downloader, I was able to download it normally. The reason why the solution to use the WinINet downloader doesn't work is probably because of the bug that occurred after the proxy support update (#4695, already resolved, but not released).
I think it is a DO timeout issue because when I used the WinINet downloader, I was able to download it normally. The reason why the solution to use the WinINet downloader doesn't work is probably because of the bug that occurred after the proxy support update (#4695, already resolved, but not released).
This is the kind of reply I like, tank you very much!!
I've checked what downloader is being used and I can confirm that is using the DO downloader.
I'll keep you up to date when the #4695 patch is released!
I think it is a DO timeout issue because when I used the WinINet downloader, I was able to download it normally. The reason why the solution to use the WinINet downloader doesn't work is probably because of the bug that occurred after the proxy support update (#4695, already resolved, but not released).
I installed f6e27a48c32c4ccdc58f5f938c5bca5c54cef2dc and, as you already mentioned, it now uses the WinINet downloader and fixes the issue. Thanks
Brief description of your issue
When downloading large files with the Delivery Optimization downloader the download randomly stops, probably because it times out. When the download stops it must be interrupted using Cntrl + C.
Steps to reproduce
Download a large package like KiCad.KiCad using the default network downloader. It will happen most of the times with a network that has only a 50 Mb/s actual throughput (this should be not so important since the download caps at 30 Mb/s anyways). Tested even on different networks and machines.
Expected behavior
The download completes correctly.
Actual behavior
The download freezes, and nothing happens. Using Cntrl + C is required to stop the download.
Environment