Audio won’t play in Internet Explorer on some servers

Hey @mcfarnell,

When using the new player, the issue could be with the version of IE, see browser compatibility here https://github.com/selz/plyr#browser-support

I tested both on Chrome and indeed they work, i tested on Edge and the dev site worked but not the live site which is odd.

I assume both instances are using the same versions of the Sermon Manager too?

Can you please try Compatibility View in IE and see if that works. See if anything here helps

Other than that i’m really not sure, but i will mention it to the Devs here too.

Igor

@mcfarnell,

I don’t mean to hijack this but am wondering if you would mind sharing how you got the sermons to display in a grid. I am using Avada as well and cannot get the sermons to display in a grid like yours are.

@sab66, you can choose how you want the archive to be displayed in the Avada settings.

@wpforchurch, I’ll try some of your suggestions and let you know. I find it really weird that it will work on some servers and not others. That makes it seem like its definitely a server issue of some sort?

@mcfarnell,

If I started another topic here would you be open to helping me out? I cannot find that option anywhere. I understand if you would prefer not to.

Thanks

@sab66,

No problem. Go to Avada > Theme Options > Blog > General Blog. Then make sure you select Blog Layout as “Large” and Blog Archive Layout as “Grid”. That should do it.

@mcfarnell,

That worked great. Thanks so much!

Hey @mcfarnell,

We figured out what’s wrong – why live site is not working.

The MP3 URL for the live website is:
https://newsite.woodlandchristian.net/wp-content/uploads/sermons/04-02-2017.mp3

The MP3 URL for the dev website is:
https://wcc.washingtontourist.com/wp-content/uploads/sermons/04-02-2017.mp3

HTTP response headers for the live website:

HTTP/1.1 200 OK => 
Date => Wed, 10 May 2017 18:32:49 GMT
Server => Apache
Strict-Transport-Security => max-age=63072000; includeSubDomains
X-Frame-Options => SAMEORIGIN
X-Content-Type-Options => nosniff
Last-Modified => Sun, 02 Apr 2017 19:16:41 GMT
ETag => "54c33e1f2f353"
Accept-Ranges => bytes
Content-Length => 16233169
Content-Disposition => attachment
Connection => close
Content-Type => application/octet-stream

HTTP response headers for the dev site:

HTTP/1.1 200 OK => 
Server => nginx/1.12.0
Date => Wed, 10 May 2017 18:34:08 GMT
Content-Type => audio/mpeg
Content-Length => 16233169
Connection => close
Last-Modified => Sat, 08 Apr 2017 00:27:14 GMT
Accept-Ranges => bytes

The biggest difference here is that live website responds with a generic application/octet-stream as Content-Type, while dev site responds with audio/mpeg (as it should be).

So, other browsers except IE do use some other checks to check if the file is actually an MP3 file.

IE sees the application/octet-stream and reports as an unsupported MIME type. (which you can see in the IE console as MEDIA12899: AUDIO/VIDEO: Unknown MIME type)

For testing purposes, we manually modified Content-Type to audio/mpeg and IE correctly detected the file as an MP3 and played it without error.

Unfortunately, just setting audio source type to audio/mp3 did not work.

So, for now, you will need to find a way to configure your server to deliver those MP3 files with a correct MIME type. Maybe you should try contacting your hosting providers for support.

We will try to add a functionality to automatically set correct MIME type, but it might be too time-consuming to do. No promises. This is the first report of this issue.