1

This question has changed significantly.

I have the latest version of Wordpress and am hosting it on an Apache server. Link to Blog: http://blogs.bzaeds.org/test/2012/05/11/video-test/

Now, here's the thing.

When I upload a video to Wordpress it will play on a Mac in Firefox with the Wordpress URL the item is given (ex: http://blogs.bzaeds.org/test/files/2012/05/720-dunk.mp4" provider="video). In fact, I can go to that link right now on my Firefox browser and have no problems, it plays fine.

However, if I upload a video to Wordpress and use the Wordpress URL (ex: http://blogs.bzaeds.org/test/files/2012/05/720-dunk.mp4" provider="video) it will not play on an iPad or iPhone.

Where this gets fun is -- if I use the APACHE location for the file (ex: http://blogs.bzaeds.org/wp-content/blogs.dir/5/files/2012/05/bunny.mp4) it will play just fine on the Mac AND the iPad & iPhone.

I have been working on this issue for 4 days and I'm exhausted. I've finally narrowed it down to this, but I'm not sure what config setting would be causing an issue like this. Any help would be greatly appreciated!

Edit: It is looking like it's the fact that Wordpress can't do byte handling and join this with Multi-site and different directories and you get chaos. I realize this is the issue, but I'm not sure what I'd do to workaround this issue and installing mod_xsendfile didn't seem to work nor editing the jwplayer code (which I'll try again, perhaps I did it wrong.)

Improve this question
7
  • Is this an issue of the video not playing in JWplayer? Or the actual video (the MP4 file you linked to) not working if you use the wrong URL?
    – EAMann
    May 10, 2012 at 21:22
  • 1
    The latter. If I use the direct URL, it works. If I use the URL wordpress creates, it does not work. Supposedly "Serving video to iOS devices does not work in Multisite Wordpress due to lack of byte-range support" Apparently iOS requires byte-range support for audio and video. Serving a static .mp4 file to an iOS from Apache works fine, but serving the same file from a Wordpress MS 3.01 installation fails. This is because the file URL is rewritten to use ms-files.php. The PHP file does a readfile($file) on the file to serve it. This is incompatible with iOS devices and will fail."
    – Ethabelle
    May 11, 2012 at 19:07
  • I tried using the guide to use mod_xsendfile because someone said that that had worked for them, but it doesn't seem to be helping me at all sigh.
    – Ethabelle
    May 11, 2012 at 19:07
  • Just to make sure, in your question one of the URLs is /2012/*04*/bunny.mp4 and the other is /2012/*05*/bunny.mp4
    – brasofilo
    May 14, 2012 at 14:18
  • @brasofilo Sorry, the urls are the same. I had to edit this because I had to delete and remake the post and I must have missed one of the links, but they are the same :) !
    – Ethabelle
    May 14, 2012 at 15:39

3 Answers 3

Reset to default
4

After 6 days of pure sadness, this ended up being the fix: http://www.technowut.com/2012/05/14/how-to-stream-videos-to-ios-devices-with-multisite-wordpress/

Here’s how to get it working on CentOS 6 with the packaged Apache httpd:

Nils Maier wrote the module for Apache httpd. Download the source and take some time to review the docs there.

Compile and install the module on the command line: /usr/sbin/apxs -cia mod_xsendfile.c

NOTE: I just used yum. :) 

yum install mod_xsendfile

If you don’t have apxs, you probably need to install the httpd-devel package.

Get that with this command:

 yum install httpd-devel

Once compiled and installed, you’ll need to enable it in your httpd.conf or .htaccess (I enabled it by putting a file in my conf.d directory). These are the directives you’ll need to set: *(Note, I put this in my /etc/httpd/conf.d/wordpress.conf file instead of the httpd.conf.)

 XSendFile on
    XSendFileAllowAbove on

Now restart Apache httpd

 /sbin/service httpd restart

Finally, you’ll need to enable the support in your wp-config.php: define('WPMU_SENDFILE', true);

Improve this answer
1

This is most likely a server configuration issue, so my answer may or may not help.

I ran both requests through Fiddler shows slightly different headers for the different URLs: The Apache URL includes an Accept-Ranges: bytes header and the WP URL includes an Expires header for caching.

WordPress URL Headers:

HTTP/1.1 200 OK
Date: Thu, 10 May 2012 21:13:01 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.3.3
Content-Length: 2911708
Last-Modified: Thu, 10 May 2012 19:32:05 GMT
ETag: "bd22bdcf21b610bcbcf0a38e3e3b40ff"
Expires: Sun, 12 Jul 2015 06:59:41 GMT
Connection: close
Content-Type: video/mp4

**Apache URL Headers:

HTTP/1.1 200 OK
Date: Thu, 10 May 2012 21:13:24 GMT
Server: Apache/2.2.15 (CentOS)
Last-Modified: Thu, 10 May 2012 19:32:05 GMT
ETag: "3ffee-2c6ddc-4bfb3acc88ad9"
Accept-Ranges: bytes
Content-Length: 2911708
Connection: close
Content-Type: video/mp4

The data returned in the body of each request is identical. The only difference is the presence/lack of those headers (and the X-Powered-By header in the WP request). If the headers aren't really the issue here, then I'd venture a guess that it has something to do with the device you're testing on (broken content in the cache perhaps?).

But both requests return the same content with the same encoding and the same content type ... they should both be handled by any retrieving device the same way. Anything broken at that point isn't WordPress.

Improve this answer
1
  • This makes sense, I have seen mention of range headers when dealing with this issue in other posts. So, are you saying Wordpress should be configured to not expire & allow range headers? In which case, do you know what config file that is to edit?
    – Ethabelle
    May 11, 2012 at 18:36
0

There's a two years old thread in JW Player forum that deals with the issue and has a workaround that may work for you, but it involves hacking the plugin code.

Longtail folks are very supportive and I suggest you open a ticket over there too. And maybe, I'm not sure, your question may be considered off-topic or too localized here.

Improve this answer
1
  • Longtail says it's wordpress, essentially. Since the player works across all platforms unless it's a link created by wordpress, they think it's the URL handling with wordpress. :( I'll check this thread out and report back though.
    – Ethabelle
    May 11, 2012 at 18:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.