Firefox and MP3s

Dear Lazyweb, if you know why Firefox can no longer play the DNA Lounge audio archives, please let me know.

"Media resource could not be decoded."

Apparently adding DRM is just fine but continuing to be able to play MP3s is beyond the pale.

Previously, previously, previously.

Tags: , , , , ,

21 Responses:

  1. Dawn says:

    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 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.

  2. pjz says:

    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.

    • jwz says:

      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.

      • pvg says:

        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...

  3. We still don't have mp3 support in the audio tag on Mac last I checked. Kinda depressing.

  4. Peter Hollo says:

    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.

    • Steve Jones says:

      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.

  5. Brian Enigma says:

    I'm anxiously awaiting the “just convert all your archives to *.ogg format” comment.

  6. db48x says:

    I notice that it doesn't actually try to download the .m3u file or the .mp3 file.

    • jwz says:

      The code in dnaplayer.js points jplayer at the mp3 URL, which results in an audio tag eventually, which FF then freaks out about.

      • db48x says:

        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.

        • db48x says:

          In fact, it shows up if I change the port to anything other than 8001. Curious.

          Firewall rules on the server perhaps?

  7. db48x says:

    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 "" -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 "" -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

    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.

    • jwz says:

      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:

      % telnet 8001
      GET /audio/2014/05-24.mp3 HTTP/1.0
      User-Agent: x
      Range: bytes=0-

      HTTP/1.1 206 Partial Content
      Content-Range: bytes 0-0/377117885
      Content-Length: 1

  8. Geoff Smith says:

    Working for me now with FireFox. :)

  • Previously