GNOME Bugzilla – Bug 320336
handle browser-downloaded iradio playlist files
Last modified: 2006-09-07 12:03:33 UTC
Please describe the problem: when i download a new pls file with streams it try to load it but in the "Radio" sections nothing appears. I'm running on ubuntu breezy amd64 in ubuntu hoary amd64 it worked. Steps to reproduce: 1. go to www.shoutcast.com 2. click on "tune in" 3. That's all! Actual results: i can't listen internet radio Expected results: that i listen the radio Does this happen every time? sure Other information:
Created attachment 54962 [details] [review] patch The problem is that the browser downloads the PLS file, and then hands that to Rhythmbox when it really wants to be given the url of the file. The *best* way to do this would be to tell browsers that we want the URI passed on the command line, rather than downloading the file and then passing that - but I doubt that will happen any time soon. Loading with the Load Playlist command kind of works, except that you get several radio stations show up with the different urls of the same station. If that's acceptable, this patch detects playlists when using Import File/Folder and ones passed on the command line.
Yep, i went to shoutcast, copied the link and paste it. It worked, good. But remember, in older versions it worked, i remember that in warty/hoary (6 months ago) with version 0.8.x of rhythmbox when i downloaded a pls file with firefox it was pasted to rhythmbox and it worked too. In my opinion the best thing to do is make rhythmbox able to parse already downloaded pls files... In the meantime i can listen radio with this trick... thanks
The problem with parsing already-downloaded pls files for iradio stations is that they often have several addresses listed for the same station. When Rhythmbox parses the browser-downloaded pls file, it will create several station entries, one for each address, which isn't what you really want. The above patch makes RB do that.
Patch committed to cvs. Retitling bug to reflect the actual issue.
James, indeed, I've seen the request for Radio stations with multiple sources served in a .pls to be presented grouped in the Radio list. (Please let me know if you prefer that I open a separate bug to track this is issue.) (This is Debian bug http://bugs.debian.org/323190.)
Loïc: that is basically bug 324402, but asking for the opposite handling. The problem is that there is no defined meaning of what multiple enties in an iradio .pls file means. It can mean any of the following: 1) alternate station servers, in case the first goes down 2) addresses that should be played after the first finishes, as each is only an individual song 3) addresses of the station in different bitrate/formats 4) different stations that are run by the same people. Handling 1 and 2 correctly means not displaying the later addresses, but switching to them when the earlier ones finish. Handling 3 and 4 means displaying all addresses, possibly grouped. Unfortunately those two options conflict, and there is *no* was to tell which case the particular .pls (or m3u or whatever) file should be handled as, without asking the user a highly technical question which they almost certainly don't know the answer two. In other words, we're screwed either way.
Hmm, thanks for pointing out the dup. I agree this is not an easy situation. In other words, there are two types of handling that people desire: 1/ adding a .pls is like adding a list of different things, like songs or radio urls, and one item should be shown in the UI per entry in the .pls 2/ adding a .pls is like adding one radio station with alternate URL for different bitates or redundancy If the playlist holds only http:// entries, it can be handled either as 1/ or 2/, but in the contrary case it's likely to be handled as 1/. So I propose the following: if the playlist does not contain only http:// URLs; then consider the entries in the playlist as separate items (1/) else ask the user whether this is a single radio station with alternate URLs It's far from perfect, but covers some cases transparently and others are left up to the user to decide once.
BTW, shoutcast.com is a popular website where such .pls with alternate URLs are served.
Looks to me like #324402 is pretty much a dupe of this. Please see comment 4 in that bug for some thoughts. http://bugzilla.gnome.org/show_bug.cgi?id=324402#c4
The two bugs are actually opposites. With browser-downloaded playlists, we don't know the actual playlist address, so *can't* handle them like bug 324402 suggests.
Created attachment 63209 [details] [review] patch This makes playlist handling about as smart as it can be, without asking the user for help, and fixes a few other issues with iradio playback. There still seem to be a few glitches here and there, though. When adding a station, if the playlist is local, it adds the playlist contents, otherwise it adds the playlist itself. It handles cases 1 and 2 (at least when the db entry points to the playlist) by storing the list of stream urls from the playlist, attempting to play each in turn. The 'retrying too quickly' check is only triggered once all stream urls have been tried. It doesn't handle case 3 or 4, but these don't happen much in my experience. For multiple bitrate/format streams, it seems there are usually separate playlists, rather than multiple stream urls in the same playlist. I think the only place I've seen multiple unrelated streams in a single playlist is rb's iradio-initial.pls file.
Are the LOCAL_IRADIO_PLAYLIST/REMOTE_IRADIO_PLAYLIST bits (in s) supposed to be there? because they aren't defined any where, and the variable isn't used. Futhur down in that function, there is an if statement with = instead of ==. It looks fairly sane, and works well from my quick testing (with the above issues fixed).
Looks fine to commit, with those compiling issues fixed.
OK, I've committed the patch with a few additional fixes.
*** Bug 354752 has been marked as a duplicate of this bug. ***