Update (ie. download) never stops for a given app.

[TerDale]

Hi,

 

I have 100+ apps configured in my jobs.db, and everything works fine. So far so good.

However, today I just wanted to add one more app, namely Rapid Environment Editor, it is distributed either in exe or zip format. Whatever the format, if I specify the URL to download the app, Ketarin appears to start downloading it, but:

- it displays "(unknown)" on top of the progress-bar, instead of the actual size of the file,

- and once it reaches the end of the progress-bar, it starts over from the beginning,

- I once thought that I should let it go, and that this behavior was due to the fact that Ketarin wasn't able to determine the file size, but even after a while the 900 KB file is not yet downloaded.

 

What is so special with downloading from this site? Do I have to change some Ketarin setting for this specific app to work around this issue?

TIA

[TerDale]

Same issue with Cygwin...

[shawn]

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?

[TerDale]

Hi Shawn,

 

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.

Thats exactly what I suspected, hence why I waited for a while. Maybe, not enough though, will try again...

 

That said, if you can use a download location that provides these headers, you'll get a much better experience.

Agreed, but I used to trust only a very few 3rd party sources, of which FH. Unfortunately FH doesn't host RapidEE.

About FH vs. x64 I strongly suspect site owners are still using x86 boxes Find it regrettable too, though should change hopefully...

 

I made a quick app profile for RapidEE. It works,

Do you mean that the download ended up to succeed?

 

Thanks for your help.

Edited December 16, 2011 by TerDale

[TerDale]

Thats exactly what I suspected, hence why I waited for a while. Maybe, not enough though, will try again...

Hmm... I'm really puzzled... When trying again it worked perfectly, IOW showing the total size instead of "(unknown)" and ending up in a few secs!?!

As I downloaded it with manually (ie. with my browser as opposed to with Ketarin) yesterday, I deleted the file after this first success, thinking that K could deduce the size from the previously DLed file, but trying once more succeeded again... Kind of magic or is the size saved in the app profile?

 

Anyway, I decided to try again also for Cygwin, and this time I got the same behavior as initially described. However, I waited longer for the end, and I can confirm what Shawn noticed: the DL eventually succeeds but it is much longer than usual.

[shawn]

How are you naming the files? I've also seen download delays when the filenames attempt to use the date information from the downloaded files within the resulting filename.

[TerDale]

Hi Shawn,

 

How are you naming the files? I've also seen download delays when the filenames attempt to use the date information from the downloaded files within the resulting filename.

Thanks for the heads up. Here is my template for "Download Location-Save to file" : "{base}\{branch}\{category}\{appname}~{version}~{url:basefile}.{url:ext}". So, it relies on the original name of the file, will try with "Save to folder" to check if that helps, and will let you know.

[Guest Brande02]

You got a very great website ketarin.org , Glad I noticed it through yahoo. regards