Download problem finally solved?

[davidb2b]

I can't say for sure, but it has been almost a week since this issue occurred. It is possible that some user connections were a little slow and that the transfer timed out before files had fully downloaded. This problem would have rarely arisen in the past when most files were about 300-500 MB, but lately, many are over a GB in size.

I expanded the php memory and increased the allowed process time by a factor of about 15. This should enable the processes to run long enough and for sufficient RAM to be allocated to the task. Now just time will tell if this has indeed overcome the problem.

[threeheadedmonkey]

Hi!

Registered on the forum so I could comment on this...

I'm one of those affected by the download size issue.
I just tried again, and am not seeing any difference:
My reference file is Unlocking_the_Flood.mp4 at 478.36MB, which keeps restarting on Chrome after ~300MB (and last time I tried Firefox just outright failed after the same amount).

I've got more than 10 other files that I can't download with the same issue but which I haven't tried for a few weeks - Unlocking the Flood is the smallest of the lot exhibiting the issue.

As a side note, the download speed seems to be capped at 700kB/sec, which I suspect is intentional but wanted to mention just in case.

In case it's region dependent, you can find my location in your store database under the same username.

[davidb2b]

Hi!

Registered on the forum so I could comment on this...

I'm one of those affected by the download size issue.
I just tried again, and am not seeing any difference:
My reference file is Unlocking_the_Flood.mp4 at 478.36MB, which keeps restarting on Chrome after ~300MB (and last time I tried Firefox just outright failed after the same amount).

I've got more than 10 other files that I can't download with the same issue but which I haven't tried for a few weeks - Unlocking the Flood is the smallest of the lot exhibiting the issue.

As a side note, the download speed seems to be capped at 700kB/sec, which I suspect is intentional but wanted to mention just in case.

In case it's region dependent, you can find my location in your store database under the same username.

Sorry you're having these problems. For the record, there is no cap on download speeds; the site runs off a dedicated server. When I download files from it through the store, they transfer at about 10 MB per second, because I myself have a high speed internet connection. I'm a few thousand miles away from the server and I get no preferential treatment.

If download speeds are capped, this is probably at your end. Your ISP may cap your account, especially if you have exceeded some monthly limit. There is also the stability of one's internet connection. I'm just guessing here, because I know the server is operating just fine. Over 95% of buyers don't experience any download issues, so it clearly has to be some factor(s) specific to those customers affected by this.

I have tried everything I can to address this problem, and I have nowhere else left to turn. My only suggestion is to buy future movies from Clips4Sale. As for the ones you have purchased, I can supply these to you manually.

[threeheadedmonkey]

Yeah, it's annoying but I'm sure we'll get it sorted in the end.

Re speed cap:
Very interesting. My internet connection is 50 MBit, so ~6MB/s are normal for me, and I've never experienced any limiting elsewhere.
There's also the fact that your hosting provider is presumably quite a lot further away from me than from you, but in that case I'd expect speeds to fluctuate, not be *exactly* 700kB/s (+/- 10s of kB) at all times.

I'll play around a bit with different connection options (4G, VPN, ...) to see if it makes any difference and get back to you.

[davidb2b]

Yeah, it's annoying but I'm sure we'll get it sorted in the end.

Re speed cap:
Very interesting. My internet connection is 50 MBit, so ~6MB/s are normal for me, and I've never experienced any limiting elsewhere.
There's also the fact that your hosting provider is presumably quite a lot further away from me than from you, but in that case I'd expect speeds to fluctuate, not be *exactly* 700kB/s (+/- 10s of kB) at all times.

I'll play around a bit with different connection options (4G, VPN, ...) to see if it makes any difference and get back to you.

I'm on the opposite side of the USA to the server in question. The number of cases has diminished but a few remain. So strange.

[threeheadedmonkey]

Right, so I've run some experiments to try and home in on the issue. Here are my findings:

• It appears that my previous statement of "exactly 700kB/sec" was wrong. Tonight, download speeds fluctuated between 550kB/s and ~720kB/s on all channels that I tried.
• I tried downloading the same file via my usual connection, then through 4G and finally through my usual connection but using a VPN to "place" me into the US.
• Whilst connected via VPN, I downloaded via Chrome on Windows and via the "curl" command line utility on Linux
• Download speeds were roughly the same in all cases, with 4G being slightly slower.
• All transfers failed after anywhere between 280MB and 360MB, again with the 4G one failing the earliest.
• I also timed some of the VPN transfers to see if it could be timing-related. They failed after 7:39, 8:24 and 9:33 minutes, respectively.

The last point is particularly interesting.
While this tells me that it's not some kind of constant timeout that fails after x seconds, there might still be a timing issue.

Dave, do you think you can somehow throttle your personal connection so that you only get the ~700kB/s I'm seeing so you can try and replicate my observations?
Because I think it could still be timing-related, but only in an awkward way where *something* happens on the server after a download has been running for 7-10 minutes, killing it.

On a related note, "curl" (and all common browsers including Chrome and Firefox) supports continuing interrupted transfers by sending a "byte range"-flavor request. "curl" says "HTTP server doesn't seem to support byte ranges. Cannot resume." - this is in line with neither Chrome nor Firefox being able to resume a download after it's been terminated. Are you aware of an option in your system to enable this? Might be a useful workaround if we can't fix the underlying issue...

[davidb2b]

Right, so I've run some experiments to try and home in on the issue. Here are my findings:

• It appears that my previous statement of "exactly 700kB/sec" was wrong. Tonight, download speeds fluctuated between 550kB/s and ~720kB/s on all channels that I tried.
• I tried downloading the same file via my usual connection, then through 4G and finally through my usual connection but using a VPN to "place" me into the US.
• Whilst connected via VPN, I downloaded via Chrome on Windows and via the "curl" command line utility on Linux
• Download speeds were roughly the same in all cases, with 4G being slightly slower.
• All transfers failed after anywhere between 280MB and 360MB, again with the 4G one failing the earliest.
• I also timed some of the VPN transfers to see if it could be timing-related. They failed after 7:39, 8:24 and 9:33 minutes, respectively.

The last point is particularly interesting.
While this tells me that it's not some kind of constant timeout that fails after x seconds, there might still be a timing issue.

Dave, do you think you can somehow throttle your personal connection so that you only get the ~700kB/s I'm seeing so you can try and replicate my observations?
Because I think it could still be timing-related, but only in an awkward way where *something* happens on the server after a download has been running for 7-10 minutes, killing it.

On a related note, "curl" (and all common browsers including Chrome and Firefox) supports continuing interrupted transfers by sending a "byte range"-flavor request. "curl" says "HTTP server doesn't seem to support byte ranges. Cannot resume." - this is in line with neither Chrome nor Firefox being able to resume a download after it's been terminated. Are you aware of an option in your system to enable this? Might be a useful workaround if we can't fix the underlying issue...

Thanks for carrying out these experiments.

The php process time is set at 500 seconds, corresponding to 8.67 minutes. The default is 30 seconds. Obviously, most downloads take longer than that so it's not a linear relationship.

I have no idea how I could throttle my download speeds. Sorry.

As for the failure of the server/php to resume a transfer, I would not know how to force it to do that. I can ask the hosting company to look into it, but I'm afraid it is beyond my abilities.

[threeheadedmonkey]

Interesting about the process time. It seems a likely candidate, but wouldn't fully explain how I was able to go up to 9 minutes in one attempt. Perhaps worth increasing it to something ridiculous (like 5000 seconds) just to see what happens?

By the way, I think I've found a way to get you throttled downloads:
https://www.freedownloadmanager.org in conjunction with https://addons.mozilla.org/de/firefox/a ... ger-addon/ (or whichever browser you prefer - I think they've made a whole range of extensions)

You can tell it to download only at certain speeds via the settings.

I just used it to download at only 250kB/sec, and - surprise! - the download failed after 121MB and... 8:02 minutes.
I'm pretty sure at this point that it's a timing issue.

As for possible causes or solutions even - no idea, not my field of expertise, I'm afraid. I'm happy to act as a test subject for possible fixes, though.

[davidb2b]

Interesting about the process time. It seems a likely candidate, but wouldn't fully explain how I was able to go up to 9 minutes in one attempt. Perhaps worth increasing it to something ridiculous (like 5000 seconds) just to see what happens?

By the way, I think I've found a way to get you throttled downloads:
https://www.freedownloadmanager.org in conjunction with https://addons.mozilla.org/de/firefox/a ... ger-addon/ (or whichever browser you prefer - I think they've made a whole range of extensions)

You can tell it to download only at certain speeds via the settings.

I just used it to download at only 250kB/sec, and - surprise! - the download failed after 121MB and... 8:02 minutes.
I'm pretty sure at this point that it's a timing issue.

As for possible causes or solutions even - no idea, not my field of expertise, I'm afraid. I'm happy to act as a test subject for possible fixes, though.

I will give it a try. However, logically, timing cannot be the entire issue. It was set at 30 seconds by default, and at least 95% of customers were able to download without a problem. I'm sure hardly anyone has been able to download one of my video files in under 30 seconds. There is, therefore, another underlying cause and that's what I need to uncover. Alas, I'm not sure I will because the number of possibilities seems large and the issue so sporadic.