Offhand, I'm not sure. My first inclination is to look at plugins you might be using in your browser. Are you on Firefox? Are you downloading using a manager, or the browser's built-in downloader?

Since HTTP transfers can be a little wonky, my guess is that it's something either lagging the browser and dropping the file... or something else. I've only heard of this occuring for a couple people, and I think that might be an email we just received on our end as well. You should be able to keep resuming the file until it's fully downloaded. However I'd like to get the bug figured out, if it is a bug. (It might be some kind of PHP issue as well.)

Hmm.. interesting. Do you have this same issue with any smaller files? Have you noticed any type of "cutoff" where the filesize becomes too big for the transfer? I'm just trying to flesh out some ideas... there is the possibility that it has to do with script timeout or running out of memory.

I know you mentioned there were no Watchdog errors, but have you checked Apache?

I've also modified php.ini for the following:

max_execution_time = 600

default_socket_timeout = 600

could this be a problem?

Yeah I'm not really sure at this point... I think it might be specific to your server, since we have files that are 1GB+ and we haven't been told of a lot of issues. Since yours seems to be reproduceable, then there might be something in your config that is causing it. Of course there could be other issues at hand but we'll need to narrow them down.

The cache idea is an interesting one but the file downloads don't actually involve the cache system AFAIK.

One thing you might look into is the file_request variable at the top of uc_file.module. I think this is the root cause of issues that we are seeing. Try editing the module, if you are inclined, to not worry about the number of requests. (I think it's set to 50, and it stores this value in the cache table... there is the possibility that this is your root cause as well.)

My suggestion is to just find another way to cache the requests; since a user could be getting simultaneous connections from their browser or manager, the number of requests will be skewed higher. Even though you are only downloading the file once, your multiple connections are hitting that cache function a bunch of times.

So... to reiterate. Try commenting out the function (or the lines in the function) that increment the cache value and then check to see if they've gone over the limit. Then try again and see if that solves it.

The File Download stopped at 610MB at 4:45PM.

I opened a support request with them last time i was working on this problem, and they were unhelpful. They did the same testing that I am doing now, and couldn't find any problems, since they were downloading it straight off of their own system.

Very frustrating experience with their tech support.

Thanks for the tip, we do have some users who tried a download manager or accelerator, but in my test environment, i'm using just FireFox and it's built in download manager.

IIRC I think Firefox 3's system is the same (or at least similar to) the way a Download Manager works. I know this because when I was testing, I found that my patch worked fine in FF2 but not in FF3, and it turned out that FF3's system also requires ETags (and something else, I believe) or else it wouldn't resume.

However this isn't an issue with resumes, per se, but I'm wondering if these issues are related somehow.

I'm sorry no, I don't know of any other command. Funny they wouldn't give you permission to execute such a benign command. Maybe you can convince their support to grant you permission.

It's a shared server, the call it "Grid Service"

Any recommendations on a host? I'm really hesitant to switch hosts unless I know this will work for certain on a new system.