download timeout

[deesee]

listed in the bugfixes for 1.3.8a is:

"BugFix: changed download timeout to 20 minutes if server allows it, to aid in larger downloads not ending prematurely"

is there more information on this? what exact value - and where - was changed?

this is a problem on my site, so i'd love to know more about how this was fixed.

[kobra]

changed download timeout to 20 minutes if server allows it

20 minutes of cpu will get you suspended on most shared hosting

Get with your host and find out the environmrnt setup they provide.
Assuming you are on a linux server, how/what is the php handler?
Some of the options are:
as a module
DSO
Fastcgi
suphp

[deesee]

20 minutes of cpu will get you suspended on most shared hosting

Get with your host and find out the environmrnt setup they provide.
Assuming you are on a linux server, how/what is the php handler?
Some of the options are:
as a module
DSO
Fastcgi
suphp

what is the 20 minutes related to, though (what process/processes)? would this mean that downloads must take 20 minutes or less to complete successfully?

i am hosting audio sample libraries, and my files are quite large (>1GB, even after breaking it up into smaller bits), so I need to be able to reliably provide downloads for my customers. right now, that's not the case.

i have been getting around this by manually providing customers with a shared/protected web folder which contains the files - and it works for them every time - but obviously that's no where close to an ideal solution.

i am on a linux host, and i'm using PHP4 with CGI/FastCGI

thanks.

[kobra]

i am on a linux host, and i'm using PHP4 with CGI/FastCGI

Is this yours or shared??

Most TOS's for shared hosting have something akin to up to 25% CPU for no more than 3 min or less.

[DrByte]

"BugFix: changed download timeout to 20 minutes if server allows it, to aid in larger downloads not ending prematurely"

That relates to this line in /includes/modules/pages/download/header_php.php:

    // override PHP timeout to 20 minutes, if allowed
    @set_time_limit(1200);

... and only applies if you're using Download By Streaming.

[deesee]

That relates to this line in /includes/modules/pages/download/header_php.php:

    // override PHP timeout to 20 minutes, if allowed
    @set_time_limit(1200);

... and only applies if you're using Download By Streaming.

ah ha! thank you, drbyte :)

so, i have redirect set to FALSE and streaming set to FALSE, but my customers are still experiencing downloads that end prematurely (no errors given, they just stop, as if they are finished).

do you have any idea what could be causing this?

again, if i give my customers a login/password to a protected web folder i have created, they are able to download with no problems - so i am sure it's not an http issue.

it almost seems as if somehow an incorrect filesize value is being passed to the browser?

[DrByte]

so, i have redirect set to FALSE and streaming set to FALSE

Why ?

[deesee]

Why ?

i tried both redirect and stream and both resulted in incomplete downloads.

i set both to false to try and eliminate places for error.

[DrByte]

Using Download By Redirect is the same as using http like you mentioned before. All it does is create a download point, and points the customer to that to do the download the same as if they'd clicked a link you supplied in an email.

[deesee]

Using Download By Redirect is the same as using http like you mentioned before. All it does is create a download point, and points the customer to that to do the download the same as if they'd clicked a link you supplied in an email.

apparently not, as the alternate (outside/separate from zen cart) links i provide to customers works every time.

just to be sure i wasn't crazy, i switched redirect to TRUE, made sure /pub was 777, throttled my bandwidth to 50k/s (to be sure it'd take a long time to download), and as predicted, the download ended prematurely after only 57MB.

this is a serious problem