"Media resource http://cerebrum.dnalounge. com:8001/ audio/ 2014/ 05-22d.mp3 could not be decoded."
Apparently adding DRM is just fine but continuing to be able to play MP3s is beyond the pale.
Firefox and MP3s
Dear Lazyweb, if you know why Firefox can no longer play the DNA Lounge audio archives, please let me know.
Tags: dnalounge, firstperson, lazyweb, nscp, webcasting, www
21 Responses:
When I click on links on your archive page your player dingus is indeed broken although I didn't notice any error message.
If I load up http://cerebrum.dnalounge.com:8001/audio/2014/05-22d.mp3 directly then I can hear the first 47 seconds and then it hangs. Since I can hear music I guess that means its not a decoding issue.
It spits that in the error console.
FWIW, going to the mp3 directly works fine for me, but the m3u fails with the error you quoted. (Firefox 29 on xubuntu)
Could it be something as simple as wrong line-endings in the m3u? (from what I can tell every OS wants native line endings, so solving that (if that's what the problem really is) is left as an exercise to the reader.
I'm talking about the jPlayer at the bottom of the window.
And no, the m3u is fine, the mp3 is fine, all of this works in every other browser in the world and used to work fine in Firefox.
Inexplicably, the live streams and DNA Radio still work. But -- and this is fun -- they stop working if you change their URLs to end in .mp3 inside dnaplayer.js. Again, only in Firefox. Which is a special little flower.
They seem to stop working in FF altogether (the requests for the mp3s, that is) the moment jPlayer touches them and fails. That is, you can take the URL to the mp3 jPlayer failed on, paste it into the bar and get nothing. The odd thing is that the request actually goes out but no response comes from the streaming server at all. Clear the FF cache and the raw mp3 URLs work. Chrome and FF (from jPlayer) seem to send slightly different headers - different cache headers, FF uses range, Chrome doesn't. Similarly, FF gets back a 206, a content length of 1 and nothing else. Chrome seems to get an mp3.
Maybe if you can talk jPlayer into doing whatever it is it does in Chrome in FF, all of this will go away. Then again...
We still don't have mp3 support in the audio tag on Mac last I checked. Kinda depressing.
Then why do the live streams and DNA Radio work? jPlayer says "solution = html" which means it's playing audio using the audio tag, not Flash.
Oh, turns out I lied to you, we got that in Firefox 26:
https://bugzilla.mozilla.org/show_bug.cgi?id=914479
We still don't have native h.264 support on OS X, which is the still-open bug I was thinking of.
The test on this page seems to confirm that mp3 is not supported in the audio tags in Firefox.
Weirdly though, for me in FF 29.0.1 on Mac your jPlayer works just fine. I'm on the latest Flash plugin from what I can see, latest OSX.
I did tamper with the plugin settings at some point to make sure that bare mp3s always do open up the save dialog rather than playing in the browser via Quicktime, so maybe that makes a difference.
The MP3 test on that page works just fine for me (FF29.0, Ubuntu) and so do my own tests with the <audio> tag. I get the reported error in the DNA archive player though. I'm not sure if that sheds any new light on the issue or not.
Not overly helpful, but another data point.
I'm anxiously awaiting the “just convert all your archives to *.ogg format” comment.
I notice that it doesn't actually try to download the .m3u file or the .mp3 file.
The code in dnaplayer.js points jplayer at the mp3 URL, which results in an audio tag eventually, which FF then freaks out about.
If I remove the port from the url it at least shows up in the network tab of the dev tools as an http request.
In fact, it shows up if I change the port to anything other than 8001. Curious.
Firewall rules on the server perhaps?
I used the ever-handy 'Copy as cURL' feature of the Firefox dev tools, then removed things until it stopped working:
db48x@anglachel:~/temp$ curl -O "http://cerebrum.dnalounge.com:8001/audio/2014/05-24.mp3" -H "User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:32.0) Gecko/20100101 Firefox/32.0"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 359M 0 192k 0 0 40287 0 2:36:00 0:00:04 2:35:56 40288^C
db48x@anglachel:~/temp$ curl -O "http://cerebrum.dnalounge.com:8001/audio/2014/05-24.mp3" -H "User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:32.0) Gecko/20100101 Firefox/32.0" -H "Range: bytes=0-"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1 100 1 0 0 1 0 0:00:01 --:--:-- 0:00:01 1
db48x@anglachel:~/temp$
It's the Range header that makes your server not respond correctly. No idea why the "failed" request doesn't show up in the dev tools; it's a perfectly normal 206 response, but with a Content-Length of 1.
I think you're saying that my server is responding incorrectly when a Range header is present, and I don't think that's true. "Range: bytes=0-" is synonymous with "Range: bytes=0-0" which means "return the first byte only" and that's exactly what it does:
Err, no. RFC 2616 section 14.35.1 says "If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the entity-body, last-byte-pos is taken to be equal to one less than the current length of the entity-body in bytes."
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35
Well, shit!
Yup, that seems to have fixed it. Thanks!
You're welcome :)
Working for me now with FireFox. :)