Some things that I know are busted, that I could really use some help with:
- 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.
- 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?
- 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?
- 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:
- 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.
I may be the only person left trying to do this... but anyway, trying to listen to some of the archive in Linux using Chrome. The m3u links don't appear to be working for me, nor does the jplayer at the bottom. I'll mess with it a bit more and see if I can figure it out (then post here).
I may be the only person left trying to do this... but anyway, trying to listen to some of the archive in Linux using Chrome. The m3u links don't appear to be working for me, nor does the jplayer at the bottom. I'll mess with it a bit more and see if I can figure it out (then post here).
Hm... also does not appear to work in VLC in Ubuntu (I think)... but if I open a VirtualBox Windows7 and open it in VLC there then it *does* work. Grumble.
Woot... the top level radio link *does* play straight in Ubuntu Chrome! :-)
Woot... the top level radio link *does* play straight in Ubuntu Chrome! :-)
One more success report: If I open VLC in Ubuntu separately, tell it to "Open Network Stream" anc copy/paste in the URL of one of the archive links... music!
One more success report: If I open VLC in Ubuntu separately, tell it to "Open Network Stream" anc copy/paste in the URL of one of the archive links... music!
I wonder what mixcloud uses, since those work great.
I wonder what mixcloud uses, since those work great.
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.
A better example than, say, Netscape 4?
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.
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.
I'm impressed, it works fine on Android on my Nexus 7. No stalling or weird stuff. Seeking even works if you're patient.
Re: #3, would it be insane to periodically poll icecast's status.xsl to acquire the current song?
If that's the insanity needed to make jPlayer work properly, I sure wish I wasn't the one who had to implement it.
Reports:
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.