Large file downloads may not be counted due to database timeout

On further investigation, it seems that the issue has to do with file time to download. If the file downloads in 30 seconds, the increment counts and sticks. If it takes that same file 2:28 (I simply kept trying until I had a slower download experience), then it does not increment. I have a larger file that I also use and it routinely takes 5 mins or so to download. It never increments. But the smaller file, if it downloads in its typical 30 seconds, it does increment on the initial click and sticks after page refresh.

I note that this user (comment #15) seems to have had this same experience and developed some work around: http://www.ubercart.org/forum/support/6671/file_download_limit_not_working

Is this a clue and can his solution either be implemented in the code or perhaps you can suggest some other workaround?

OK, here's what I did. I'm using the DEV version of Ubercart and the relevant file is uc_file.pages.inc

The result is that now when I click to download, it does not revert to the earlier counter increment on those files that take longer than 30 seconds.

 // Open the file and seek to starting byte
  $fp = fopen($file_user->full_path, 'rb');
  fseek($fp, $seek_start);

	//move up here from line 351 Dan Royer
    _uc_file_log_download($file_user, $ip);

  // Start buffered download
  while (!feof($fp)) {

    // Reset time limit for large files
    set_time_limit(0);

    // Push the data to the client.
    print(fread($fp, UC_FILE_BYTE_SIZE));
    flush();
    ob_flush();
  }

  // Finished serving the file, close the stream and log the download to the user table
  fclose($fp);
 // the original line moved above was here
 
}

I guess this means the count happens even if the file download gets interrupted.

I'd be happy to let you onto the account to see for yourself. We sell two files--one is larger than the other. The smaller typically downloads in about 30 seconds and it increments and stays as it should. The larger increments on the initial click but does not stick after completion and page refresh--until I moved the code like you see above--which I don't like doing of course.

Is it a complete download? Yes, it's an install file and I can download it then install it. We'd be getting a lot of complaints of incomplete downloads if it wasn't a complete download.

The pattern is that the counter would click up one on the initial click to download (as it should). After the download completes, the counter stays as it should until the page is refreshed (or leave the page and return) and then the counter is back to what it was before you started the download. This happens every time with this larger file. The smaller file it never happens on *unless* the file takes a bit longer to download.

Whatever I can do to help or demo this for you, I'd be glad to. Just let me know.

Dan

Yes, actually I do get about 10 rows of server log, all related to mysql server going away error.

What does this mean? Does this mean there is some problem in my configuration? Or does it mean there is something to fix in the module?

However, this is not preventing a complete download. Does that make sense according to your understanding of that error?

Thanks for pointing to that lead.

Dan

Hmm. The ping trick? I wonder how I could set the connection time higher or something?

Thanks for your thoughts on this. I'm not sure if somebody wants to fix the module--or whether this is a legit bug or a user setup problem.

But the out-of-the-box mysql set up has, I think, a 30 second wait_timeout. Mine did.

I used this module:

http://drupal.org/project/drupal_tweaks

to change that wait_time out to 6000 seconds--the longest time needed for my larger file download (most can download in about 4-5 mins). This solved the problem. Now the increment sticks after the download complete because the MYSQL has not "gone away."

Thanks for the help. I hope this db "tweak" doesn't have any unwanted consequences.

Dan

Thanks for your comments that led to understanding the problem. I'll leave my db tweak until it gets fixed and then perhaps set my time out back to 30 seconds or a minute. There is probably some reason the default is 30 seconds.

Ugh, unfortunately the database tweaks that allows me to set a higher wait timeout is interfering with my secure pages now. I guess I'll have to wait for this bug fix before i can use the file downloads.

turns out the wait_time setting is in etc/my.cnf file. I raised that limit and all is working again.

Dan

Guess I'm back to the hack until someone can create a fix for this issue. Turns out that moving the line as in comment #2 may be the only way to record downloads for now. Thought wait time out was the issue, but maybe not.

I don't know if it would help to have the log, but I can show that if needed.