A request to phade. (Using limited download managers)

[Dan42]

This exactly how the system works. A flag is set at the end of the script saying that the download is completed. This flag should only be set if the script has handed out the entire file.

Indeed, the flag should not be set... but it was. Weird bug.

The issue you have encountered must be something specific to DAP or something that Mozilla manager corrects for. Does DAP have a FAQ for setting up a server script to work with DAP?

No, I'm not aware of a DAP-specific way of setting up a server script, but then again the example code I provided was developped using DAP. So it *should* work. Then again, we all know how much bugs care about "should work", right?

Having the restart happen immediatly after a cancel is exactly the thing I am trying to avoid. register_shutdown_function will run every time the script ends and thus will only run on completion, which does not help solve the problem. The problem is detecting the time between the last attempted download and the current one.

Sorry to contradict you, but I just ran a test script and the function registered using register_shutdown_function was called when I interrupted the loading of the page with the stop button of my browser. Also, why do you want to avoid a restart immediately after a cancel? I thought the point was to foil simultaneous connections, not successive connections.

Since I want to use DAP, I hit cancel and I drag the link into the DAP window.

Did you drag the link to the page that you are viewing that starts the download or the link to the video itself?

The link to the video itself, the one that appears after 1 second.

The only possible printed errors for the file download script are:

* ERROR: File does not exist.
* ERROR: Video is not available for download.
* ERROR: You are attempting to download this video too soon after your last download attempt.
* ERROR: Link information currupted.
* ERROR: You do not have permissions to download local videos.

If I try to download the video too soon, I get a file with "ERROR: You are attempting to download this video too soon after your last download attempt." but if I wait one minute before hitting the "Start Download" button, I just get an empty file!

[gypsy]

I use Fresh Download for all my non local downloads and it doesn't pick up the link.

The only way I see the script hapening is if there's a direct link to the video file. The download managers are set to pick up links with avi/mpeg/whatever and then it saves that.

The code used prevents the download manager from getting that link.

Mab the person can cancel the link and then the direct link can then appear after the script whent through.

OR

Make a VERY SMALL link somewhere on the page and give only the info for people who donated. Telling them where they can find a direct link to the vile to download in a manager. Something like a hidden link. (White text somewhere on a white block)

That way not too many people will know of this and the service shouldn't get abused. I still think there should be an ip monitoring thing somewhere and if more than one download is picked up the user should be booted / banned.

Thanx

[Phade]

Hey,

Make a VERY SMALL link somewhere on the page...

There is a link that appears after 10 seconds for non-donators (1 second for donators) than you can use. Of course if you cancel the initial download, you must wait the 60 seconds before attempting to download again.

Registers the function named by function to be executed when script processing is complete.

I took this to mean that the function will run when the script has been processed completely, not if the script is canceled. This may be a bug in PHP or a bug in the documentation.

The download process logs the download attempt and then logs the success when the download has completed. The time checker looks at the time of the last attempt and sees if it was more than 60 seconds ago. Yet, we digress: We are not looking for a solution to "restart immediatly after cancel"; we are looking for a solution to "resume the download after 60 seconds".

We need to find out what the difference between Mozilla's download manager and DAP that is causing the trouble and how to correct it (since I was able to successfully pause the download and then resume it after considerable time using Moz). The two managers must be doing something different to track and/or resume the file that needs to be continued. Thoughts?

Phade.

[Dan42]

Combined with connection_aborted, register_shutdown_function can be pretty powerful.

Thoughts?

Without seeing the exact code that you used it's a little difficult to hypothesize on the problem. But I assume it's pretty similar to the example code I gave. So in that case, the only difference (that I can see) appears to be the 60-second delay... maybe it's messing up what DAP expects when contacting the server. I suggest you make a test script where the 60-second delay is removed and then I'll retest with DAP and see if anything goes differently.

[Dan42]

Hum... I just upgraded from DAP 5.3 to 5.3.9.6 and now I'm able to download the file... except it says "Resume not supported" and restarts the download if I try to resume.

[Phade]

Hey,

Yeah, I guess the code would help. ^_^ Here's the modified code:

Code: Select all

$filesize = filesize("$thepath/$thefile");
$start = 0;
$end = $filesize - 1;

// log download attempt...
$query = "insert into video_download_attempt_log (vid_id, user_id, date_attempt) values ($v, $cookie_user_id, now())";
mysql_query($query, $dbconn);

// get attempt_id...
$query = "select attempt_id from video_download_attempt_log where vid_id = $v and user_id = $cookie_user_id order by date_attempt desc limit 1";
$result = @mysql_query($query, $dbconn);
$row = @mysql_fetch_object($result);
$attempt_id = $row->attempt_id;
			
// check for resume download request...  
if ($HTTP_RANGE) {
  // partial file request made, calculate range headers...
  if (substr($HTTP_RANGE,0,6) == "bytes=") {   
    // get the requested start and end ranges...
    list($start,$end) = explode('-',substr($HTTP_RANGE,6));
    $start = intval($start);
    $end = intval($end);
    // if the end is blank-ish...
    if (!$end) {
      $end = $filesize-1;
    } // if
    // check for invalid start and end spots...
    if ($start >= $filesize or $end < $start) {   
      header( "HTTP/1.1 416 Requested range not satisfiable" );
      exit();
    } // if
    // check for valid resume spots...
    else if ($start > 0 or $end < $filesize-1) {
      header( "HTTP/1.1 206 Partial content" );
      header( "Accept-Ranges: bytes" );
      header( "Content-Range: bytes $start-$end/$filesize" );
    } // else if
    // things are screwy, so send full file instead...
    else {
      $start = 0;
      $end = $filesize - 1;
      header("HTTP/1.1 416 Requested range not satisfiable");
      header("Content-Range: bytes */$filesize");
    } // if
  } // if 
  // unknown type of range, so send full file instead...
  else {   
    header("HTTP/1.1 416 Requested range not satisfiable");
    header("Content-Range: bytes */$filesize");
  } // else 
} // if
			
// hand out the file...
header("Content-Disposition: attachment; filename=\"$thefile\""); 
header("Content-Type: application/octet-stream"); 
header("Content-Length: " . ($end-$start+1));
$fp = fopen("$thepath/$thefile", "rb"); 
fread($fp, $start);
while(!feof($fp)) {
  print fread($fp, 4096);
} // while 
fclose($fp); 
			
// log successful download...
$query = "insert into video_download_local_log (attempt_id, vid_id, user_id, date_downloaded) values ($attempt_id, $v, $cookie_user_id, now())";
mysql_query($query, $dbconn);

[Phade]

Hey,

Ahh. So now we just need to find out how to signal DAP that resuming is allowed.

Phade.

[Dan42]

And I just found out the problem. When *not* using HTTP_RANGE, the Accept-Ranges header is not sent. Since this header indicates that partial download is possible, DAP assumes that there is no resume because it's missing. You should simply move header("Accept-Ranges: bytes"); out of the if($HTTP_RANGE) block.

[Phade]

Hey,

Removed and uploaded. Try it now.

Phade.

[Dan42]

No, DAP still won't recognize that the download is resumable.

But... why did you say "REmoved and uploaded"? The Accept-Ranges header had to be MOVED out of the if($HTTP_RANGE) block, not completely removed from the script. It should be placed just before the Content-Disposition header.