Jump to content
Ketarin forum

Very slow download from SSL site


dtgm
 Share

Recommended Posts

When updating, Progress column is listed as (unknown) and Status column is Downloading

It takes about 10 minutes to download a 6.44 MB file, or about 10 kilobytes/sec when trying to get https://download.sonarr.tv/v2/master/latest/NzbDrone.master.exe.

The file slowly gets downloaded to %TEMP%\tmpXXXX.tmp

Wireshark shows:

No. Time        Src  Dst  Protocol Length Info
220 45.075596   c    S    TCP      66     40269→443 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
221 45.145408   S    c    TCP      66     443→40269 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
222 45.145508   c    S    TCP      54     40269→443 [ACK] Seq=1 Ack=1 Win=65536 Len=0
223 45.145697   c    S    TLSv1    388    Client Hello
224 45.215983   S    c    TCP      60     443→40269 [ACK] Seq=1 Ack=335 Win=30336 Len=0
225 45.216288   S    c    TLSv1    167    Server Hello, Change Cipher Spec, Encrypted Handshake Message
226 45.217521   c    S    TLSv1    342    Change Cipher Spec, Encrypted Handshake Message, Application Data
227 45.293910   S    c    TLSv1    1506   Application Data, Application Data, Application Data
228 45.294183   S    c    TCP      1506   [TCP segment of a reassembled PDU]
229 45.294334   c    S    TCP      54     40269→443 [ACK] Seq=623 Ack=3018 Win=65536 Len=0
230 45.294440   S    c    TCP      1506   [TCP segment of a reassembled PDU]
231 45.294592   S    c    TCP      1506   [TCP segment of a reassembled PDU]
232 45.294704   c    S    TCP      54     40269→443 [ACK] Seq=623 Ack=5922 Win=65536 Len=0
233 45.294785   S    c    TCP      1506   [TCP segment of a reassembled PDU]
234 45.295028   S    c    TLSv1    1390   Application Data
235 45.295112   c    S    TCP      54     40269→443 [ACK] Seq=623 Ack=8710 Win=65536 Len=0
236 45.295235   S    c    TLSv1    1506   Application Data, Application Data
237 45.295455   S    c    TCP      1506   [TCP segment of a reassembled PDU]
238 45.295543   c    S    TCP      54     40269→443 [ACK] Seq=623 Ack=11614 Win=65536 Len=0
239 45.295667   S    c    TCP      1506   [TCP segment of a reassembled PDU]
...
358 45.792728   S    c    TCP      1506   [TCP segment of a reassembled PDU]
359 45.792755   c    S    TCP      54     40269→443 [ACK] Seq=623 Ack=126322 Win=4608 Len=0
360 45.792968   S    c    TCP      1506   [TCP segment of a reassembled PDU]
361 45.793201   S    c    TCP      1506   [TCP segment of a reassembled PDU]
362 45.793217   c    S    TCP      54     40269→443 [ACK] Seq=623 Ack=129226 Win=1792 Len=0
364 45.826050   S    c    TCP      1506   [TCP segment of a reassembled PDU]
365 45.868739   c    S    TCP      54     40269→443 [ACK] Seq=623 Ack=130678 Win=256 Len=0
368 46.219441   S    c    TCP      310    [TCP Window Full] [TCP segment of a reassembled PDU]
369 46.259379   c    S    TCP      54     [TCP ZeroWindow] 40269→443 [ACK] Seq=623 Ack=130934 Win=0 Len=0
370 46.427642   c    S    TCP      54     [TCP Window Update] 40269→443 [ACK] Seq=623 Ack=130934 Win=65536 Len=0
371 46.497248   S    c    TLSv1    1250   Application Data
372 46.497496   S    c    TCP      1506   [TCP segment of a reassembled PDU]
373 46.497539   c    S    TCP      54     40269→443 [ACK] Seq=623 Ack=133582 Win=62976 Len=0
374 46.497706   S    c    TCP      1506   [TCP segment of a reassembled PDU]
...

Referer: sonarr.tv

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0

https://www.ssllabs.com/ssltest/analyze.html?d=download.sonarr.tv

http://toolbar.netcraft.com/site_report?url=https://download.sonarr.tv

 

Any ideas what is causing this?

 

 

 

Link to comment
Share on other sites

Shawn talks about the issue (https://ketarin.org/forum/topic/772-update-ie-download-never-stops-for-a-given-app/?p=5928)

 

The behavior you're seeing is what happens if the server doesn't provide information about how large the download is within the headers. In these situations, the best Ketarin can do is provide an "activity bar" showing that "something is happening" but not tell you how much of the content it's downloaded. Usually, in these situations the downloads do take longer than when the total size is known before hand...I don't know why, but I can confirm that these downloads take longer, by as much as 2-3x longer than they would if the filesize was known before hand. On some sites you might get a performance boost by ensuring that you're using an appropriate HTTP referer on the advanced settings tab (iow, a URL from this site where the download link is provided).

That said, if you can use a download location that provides these headers, you'll get a much better experience. This is one of the reasons why I personally use FileHippo for some of my downloads. It has nothing to do with their site (which seems to have something against 64bit processors and releases), but that since it sends the appropriate headers it's much easier to tell if everything is working okay.

I made a quick app profile for RapidEE. It works, but it does show the "unknown" activity bar. It's odd, too, because this one actually includes the content-length header, which is one of the headers that can be used to detect the total file size. Yet, it's showing the activity bar instead of the download meter.

Flo...any suggestions?

 

Flo never chimed in  :(

Link to comment
Share on other sites

  • 4 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.