I created a test order and was able to download the item 5 times when it was set at 3. The counter on the page changes to 1 but doesn't go past that. If I refresh the page, it is always 0. Anyone know what gives?
Thanks!!
Sat, 09/27/2008 - 16:53
Re: File download limit is not working
What version of UC is this?
Re: Re: File download limit is not working
It's the 5 'deluxe' install package - I got it here last weekend.
Thanks
Re: Re: Re: File download limit is not working
So you're saying then, that the "# of downloads" also doesn't get updated in the Files list? Are you downloading the entire file each time, or only starting it and stopping it? I think that the update only happens once the file is closed (at the completion of the download) but I could be mistaken.
If you are downloading the whole thing and the limit isn't working, I can take a look - although it seems odd that the download count wouldn't be getting updated. That works fine for me.
Re: Re: Re: Re: File download limit is not working
Yes, I downloaded the file fully each time, just double checked the file size.
Problems with file downloads
Hello, seemingly have similar issues. For example I have set the download period to 24 hours, and the file download limit to 1. It seems to increment correctly when I let the file download finish all the way. The link will become unusable.
However, when I start to download the file and about half way through I suspend the download (In Safari on Mac clicking on the "x" icon next to the downloads in the downloads window) and then resume the download at a later time by clicking the resume icon inside the Safari downloads window, I can download the rest of the file without incrementing the file downloads. So, but following that we have unlimited downloads.
So for now I will have to try to restrict the downloads by IP address also to see that I can limit this somehow, but it would sure be nice if this was working somehow.
Using the following:
Drupa: 5.10
Ubercart: 5.x-1.5
Please advise.
Thank you in advance,
Martin
Re: Problems with file downloads
Ahh, very interesting. I might direct cha0s and torgosPizza here... the code was updated to allow for download resume, but I'm not sure this was an expected behavior. 
I wonder if we should consider incrementing the count before the download starts or perhaps not allowing for download/resume if a download limit is in place...
Re: Re: Problems with file downloads
Well.. I am not sure what needs to be done here. That's why I came here in the first place 
But any help/update to the uc_file module would be appreciated
Martin
PS: Thank you for the super fast reply!
Re: Re: Re: Problems with file downloads
Yeah I guess we'll need to increment the count when the download starts. This might mean changing the way the # of download limit is handled, since now it's on the other side of the download. Not a huge fix, I don't think.
If one of you guys can't get to it, let me know. (This is launch week for us so I'm pretty busy.)
I tested it...
I cannot reproduce this. Are you going by the number of links on a user's file page to determine the number of total downloads? If so this is an incorrect indication. You should refresh and check the download links page after you've finished resuming the download.
There is no AJAX or real-time update of the download table on the user's file page. When you click it increments the number by one (if it's not above the limit) even if you don't finish the file. If you were to for instance:
Start downloading file
Pause it
Refresh file download table
You'll see that the table has not had the download you just started registered yet.
Download numbers are no incremented until 'eof'... That means until the function actually spitting out file data to the client hits the very last piece of the file, it won't increment the download count. I don't think I changed that logic, I'm pretty sure it was always this way. Resuming won't affect this, as soon as the code sees "I'm at the end of the file", the download is logged (which involves invalidating the key, adding one to downloads, etc).
You might notice the new warning I put in uc_file under the download table due to the last chunk being when the server will cut off any new attempts on the existing fid/key pair. (the weird link you get in your email)
Once your download is finished, you must refresh the page to download again. (Provided you have permission) Downloads will not be counted until the file is finished transferring, even though the number may increment when you click. Do not use any download acceleration feature to download the file, or you may lock yourself out of the download.
Reason for that is, with those download accelerators, they don't necessarily download in linear order... they might start one chunk at the beginning, one 1/4 through, one 1/2 through and one 3/4 through... now the point is if the one that's 3/4 goes a little bit faster, and completes (to the end of the file) before the others can, you've just locked yourself out of (and incremented) the download now.
HTH, please if you have a scenario I can reproduce with some steps, let me know.
EDIT: We can't log the download before the file is finished completing... otherwise we can't allow resuming at all because the key associated with that transfer will be invalidated. I don't see a problem with the current system in this regard.
Re: I tested it...
Cool write-up, cha0s. I wasn't sure if this was actually a problem... it's hard for us to test since we don't limit by download, just by IP. Anyways thanks for looking into it and clarifying.
Re: Re: I tested it...
Ok, I am not making this up. I just tested it again. I have the limits set to:
1 file download
2 IP numbers
1 day
So I go and click the download link and it starts to download the file, then let's say I click on the Mac Safari 3 (latest) cancel button in the download link to suspend the download. Then after a few minutes I go ahead and click the resume icon in the download window. And now I let the download finish. Then I go ahead and refresh the file download table page, click the file link, and bingo.. download starts again.
So, maybe I am doing something wrong here, but this is what I am getting.
Thank you for looking into this. Any further help is appreciated.
Martin
Re: Re: Re: I tested it...
I can reproduce the issue on Chrome. Here's a more detailed description:
Using the one time link from the automated email, I can download the file successfully as many times as I want. It doesn't matter if I close the browser or tab and click on the link again.
After logging in and accessing the file downloads, after I click on the file, it downloads successfully and increments by 1. However, if I do not leave the page and click on the file again, I can download it with no incrementing, as many times as I want. If I go to another page and then come back, then this behavior repeats itself.
Re: Re: Re: Re: I tested it...
In case people were wondering, this is still an issue on Chrome (1.0.154.36) and UC 5.x.1.6.
Bottom line is that for the one time link from the automated email, a user can download a digital good using Chrome for unlimited times, even if that link has been previously used to download the file via a different browser.
mlerch wrote:let's say I
let's say I click on the Mac Safari 3 (latest) cancel button in the download link to suspend the download
Not sure, but is this an actual cancellation and not a pause?
Did some poking and some testing ....
Hello again,
I know it has been a little while since I last posted regarding this issue here. Anyway, I think that anyone can reproduce the issue by simply using a larger file, like a video file for example. Let's say around 100 MB.
In uc_file.module
Function: _file_download_transfer
At the very end:
fclose($fp);
_user_table_action('download', $file_user, $ip);
exit;
}
}
It seems that when downloading a larger file like 90MB or 100MB something is timing out because the _user_table_action functions seems it is never performed. It's just not updating it anymore.
Now I tried increasing the TimeOut 300 to TimeOut 1200 in Apache httpd.conf, combined with the set_time_limit(0); function in the while loop serving up the file it really should have no reason to time out. But it does for some reason. Am I overlooking something?
I moved the _user_table_action function above the while loop that serves up the file right below the fseek function, and basically achieve the update of the download limit in uc_file_users table before the download starts. And guess what, it works fine. BUT...
Yes, here comes the big BUT..
Now if something happens during the download, like pausing the download, or not finishing the download for whatever reason, the user just used one of x downloads from the download limit set. This is of course not a desired outcome.
Does anyone have any idea why the _file_download_transfer function would never be able to finish and get to execute the _user_table_action function when serving up larger files or downloading on a connection that is slower? (since I am not really sure if it has something to do with the file size or the time it takes to download the file).
Anyway, I tested it with a 30 and 40 MB file and it did reach the end of the function and was able to execute _user_table_action and incremented the complete download.
Please let me know your thoughts.
Martin
Re: Did some poking and some testing ....
i can confirm this size issue.
the mp3 downloads at www.nowtrecords.org increment no problem (5-10mb).
the bigger zipped versions do not (100mb+) download fine but do not increment
we are also selling mp4 movies (800ish mb) download fine but do not increment
versions? ubercart 1.3 drupal 5.12
Martin:
I'm able to replicate
Martin:
I'm able to replicate this experience exactly. It has to do with time, not file size. If I get the download in 30 seconds, it increments. If it takes, say, 2 mins, it does not increment.
I see this thread was finally abandoned, but just wondered if by some chance you found a fix--or perhaps the module maintainer will see this and suggest a fix.
Dan
Re: Martin: I'm able to replicate
OK, here's what I did based on the reply above. I'm using the DEV version of 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
}
Re: File download limit is not working
this isn't working for me either...
resets to 0 every time. annoying cause i'm trying to keep track of how many times my promotional press download is actually being accessed.
Re: Re: File download limit is not working
Details? Browser, OS, Drupal version, module version?
I use this on a production and live server and have not seen this problem.
Re: Re: Re: File download limit is not working
I can reproduce the issue with the latest version of Chrome (0.2.149.30). While testing the IE bug, I found that when using Chrome, I can repeatedly download the file using either the anonymous link, or by logging in and clicking on downloading the file. The counter doesn't increment.
My system is running Drupal 5.10 and UC 5.x-1.5.
count increment and file downloads
OK, the issue is explained and a tweak to fix it is discussed here:
http://drupal.org/node/1090316
It has to do with the mysql timing out during longer download times. It is not directly related to file size, only time. Most mysql settings have a 30 second wait time and after that that trigger that updates the table is not able to work.
Dan