Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

DataObjectManager Module /

Discuss the DataObjectManager module, and the related ImageGallery module.

Moderators: martimiz, UncleCheese, Sean, Ed, biapar, Willr, Ingo, swaiba

Problem playing protected video files


Go to End


3 Posts   2818 Views

Avatar
Netrist

Community Member, 2 Posts

9 January 2012 at 9:22am

Edited: 10/01/2012 1:37am

I'm running Silverstripe 2.4.5 with the data object manager module, uploadify, and secure files module. We are moving the site from an older server running PHP 5.1.4 to a new server running PHP 5.3.3. I am using the shadowbox and flv features included in the dataobject manager to view video (flv) in pop-ups. Some videos require group membership to view, so the secure files module ensures the user has the rights to view the videos.

On the old server, there is no problem viewing protected files. The shadowbox pop-up plays the flv file. On the new server, using the same code (SS2.4.5), unprotected files can be viewed with no problems, but for protected files only 10KB to 20KB of the file is sent before the connection quits.

Here's what I've tried so far. I'm hoping someone may have some other ideas:
1) I've extracted the relevant code from the protected files module and created a pure php page that uses the same essential code but runs outside of silverstripe. When shadowbox points to this test page, the video plays as normal (had to use ModRewrite to redirect a test.flv to a test.php...but all worked fine).

2) If I have the appropriate rights, I can access the file directly by going to the url of the FLV file in the assets directory. The entire file downloads. (I also protect a few PDFs which work fine on the new server).

3) The new server has a minimal install of apache 2 and php 5.3. I added an flv type so that the video comes through with a mime type of application/octet-stream. I have reviewed other important php settings like max execution time (30 seconds). Output buffering is set to 4096, zlib output compression is off, session use only cookies is off.

4) Doing logging at each step finds that the file is opened and the buffer read and flushed about three times, then simply stops without throwing an error. Charles (packet sniffer) shows a status code of 200 OK but a message: Client closed connection before receiving entire response.

Any thoughts that may help me solve this problem?

Thanks!

Avatar
Hamish

Community Member, 712 Posts

25 February 2012 at 11:19pm

Hey Kevin,

It would be useful to see the exact code you used for (1). It's interesting that Charles reports "Client closed connection". Given the errors you're describing it seems likely to me that connection_aborted (see SecureFileDecorator Line 209 is returning true.

Another thing - do you get the same problem with other large files - e.g. if you upload an image, can you access the full image from a browser correctly? I'm wondering if there is something special about how Flash player requests the file (e.g. with Range headers or something else that might not be cleanly interacting with PHP).

Finally, have you tried using the mod_xsendfile option? It really is the best way to serve files - performance is much better and it should get around any PHP specific issues.

Regards

Hamish Campbell

Avatar
Netrist

Community Member, 2 Posts

28 February 2012 at 7:28am

Hi Hamish,

Thanks for the response and the good ideas you had. Here's what I've tried:

1) I tried removing the check for connection_aborted from the secure files controller (removed "&& !connection_aborted()"). No change in behavior. I realize there may not be a change if the client is truly aborting the connection.

2) I looked at "Accept-Ranges" in the headers. Neither old or new servers use them (and the old server plays videos). I did add an "Accept-Ranges: bytes" header but saw no change.

3) For other large files, in our case pdf, we don't see similar problems. We have some smaller videos (20mb) and some larger pdfs (2 to 3mb). The pdfs download in the background as an attachment, the videos do not play.

4) We had tried mod_xsendfile in the past with no change in behavior. We may revisit this again.

5) If I pass-off the php streaming routine to a php script outside of silverstripe, the videos do play. You'll note the code is really no different to what secure files is doing. First, I created a test.php file at the site root. Second, I changed the line of the .htaccess file in the secure folder to:
RewriteRule (.*) test.php?url=%1&%{QUERY_STRING} [L]

The code within the test.php page is:
$file_name = $_GET['url'];
$file_path = "/home/SITENAME".$file_name;
$file_size = filesize($file_path);

header("Content-Type: video/x-flv");
header("Content-Disposition: attachment; filename=" . addslashes($file_name));
header("Cache-Control: max-age=1, private");
header("Content-Length: {$file_size}");

if($filePointer = @fopen($file_path, 'rb')){
session_write_close();
doFlush();
//Push the file while not EOF and connection exists
while(!feof($filePointer) && !connection_aborted()){
print(fread($filePointer, 1024 * 32));
doFlush();
}
fclose($filePointer);
exit();
}

function doFlush(){
if(ob_get_length()){
@ob_flush();
@flush();
@ob_end_flush();
}
@ob_start();
}

Any other thoughts or things to try?

It seems like it must be a configuration issue between Silverstripe and the server environment. It does seem that the connection is being aborted or closed too early. We are considering moving to a server with a WHM/cPanel installation as that will perhaps have a PHP configuration more commonly seen with web hosting providers. (Currently we have stock builds of Apache and PHP.)

Regards,
Kevin Wood