DNA webcasts and jPlayer

I've installed jPlayer on the DNA Lounge webcasts page. This makes it possible to listen to music right on the page instead of having to rely on the vagaries of iTunes -- which has become remarkably more vague of late. Let me know how it works for you, please!

Some things that I know are busted, that I could really use some help with:

  1. On iOS, when you click on a "time" number it often just starts at the beginning anyway instead of seeking there. I don't know how to fix this. I tried setting a timer and retrying (see the code) but I can't tell how to determine when whatever-it-is-that-isn't-loaded is finally loaded.
  2. When you're using the Flash backend instead of the HTML5 backend, seeking doesn't seem to work. Maybe this is a limitation of the jQuery Flash player?
  3. On the top level webcast page, the DNA Radio link plays fine, but there's no metadata. It should be showing you the title of the song that is currently playing. I guess jPlayer just doesn't do that at all? Is there any sane workaround for this?
  4. If jPlayer doesn't implement this, I guess they're in good company, because as far as I can tell, iTunes 10 has also dropped support for Icecast/Shoutcast-style metadata. It used to work, now it doesn't.

    Playing DNA Radio in VLC shows the song titles as the songs change; playing it in iTunes just always shows "DNA Lounge Radio". (I assume VLC will drop support for this some time next week, just to keep up.)

    It used to be that iTunes did not send the icy-metadata header but would accept that style of metadata anyway if you replied with icy-metaint (which is what I had been doing), but now doing that just gets you audio glitches and no metadata, so it seems like they just deleted that code. Nice.

    If there's a way to get iTunes to show you the individual track names in an audio stream, I'd love to hear it. Or even an example of it working.

Update: Oh! I forgot to mention:

  1. The "seek" slider is unclickable on iOS. I assume there's some z-index nonsense that needs to happen, but I can't figure it out.


Tags: , , , , ,

8 Responses:

  1. Jake Nelson says:

    More and more, I wonder why the hell there are no decent music players - even in general, though streaming is certainly the canary in the coalmine. I got to the point of uninstalling iTunes and going to foobar2000 with its mid-90s aesthetic and all because of the level of crapulence, but that's hardly a good option. WinAmp was good in the 2.x days, but the 3.x rewrite is still my go-to example of second-system-syndrome, such a bloated pig (5.x was an improvement only in that it was a regression...). This shouldn't be that damned hard! Why is there nothing that works properly?

    Of course, the last two lines are how I feel about 90% of the world, but still.

    • Fred Clausen says:

      WinAmp was good in the 2.x days, but the 3.x rewrite is still my go-to example of second-system-syndrome, such a bloated pig

      A better example than, say, Netscape 4?

      • Jake Nelson says:

        Yeah, because Netscape 4 featured a lot of kitchen-sink type bloat, extra features, et al, as well... Winamp 3 was pure "let's create a new, super-generic, super-universal modular structure", y'know, Do It Right in that way people think, etc. and it didn't do anything new ("Modern" skin support doesn't count.). No one, of course, could explain what besides Winamp would ever use this new generic engine... It was basically pure de-optimization, like replacing a short Perl script with a Java app that uses all available RAM.

        • Helyx says:

          I think this happened arounf the time that AOL (I think? it was awhile ago) bought Winamp. It was a sad day indeed.

          I just used(d) VLC. It does what I want, and nothing I don't.

  2. piku says:

    I'm impressed, it works fine on Android on my Nexus 7. No stalling or weird stuff. Seeking even works if you're patient.

  3. Cody says:

    Re: #3, would it be insane to periodically poll icecast's status.xsl to acquire the current song?

    • jwz says:

      If that's the insanity needed to make jPlayer work properly, I sure wish I wasn't the one who had to implement it.

  4. Notamoose says:


    Summary: This browser-based shit don't work on the desktop, captain. :(

    OS: Android 4.1 on a Nexus S

    Google Chrome 18:
    Playback works. Switching songs works. Seeking takes a quarter minute or so. Maybe my wifi is slow as balls, or maybe the entire file is being streamed to me.

    OS: Ubuntu 12.latest

    Google Chrome 24.0.1312, without Flash:
    Clicking the "Listen" link causes the selected track in the player to change. Clicking the "Play" button on the player changes the "Play" button to a "Pause" button, but does nothing else. If I open the Chrome dev tools, and look at the Network tab, I see that the browser issues a GET for the relevant MP3, and then immediately cancels that get. Clicks on the time scrubber appear to be ignored.

    Chrome 24, with Flash:
    Exactly the same behavior as without Flash. I suppose that the HTML5 player is preferred over the Flash player on certain browsers.

    Chromium 22.0.1229:
    The same behavior as Chrome 24.

    Firefox 18:
    Requires that I install Flash to even interact with the player. The "Listen" links act as links to the underlying m3u file. I don't know what happens if I install Flash.

    Rekonq 1.1:
    Same behavior as Chrome and Chromium.

    The Chromium problems also happen on my Gentoo Linux machine, so this doesn't look like something that the Ubuntu guys caused.