GNOME Bugzilla – Bug 324402
radio playlist improvements for handling 'pls'
Last modified: 2018-05-24 10:58:35 UTC
Hi, Martin-Éric Racine reports in Debian bug http://bugs.debian.org/339860: "Rhythmbox's handling of 'pls' radio playlists could use some improvements: Right now, whenever a playlist is passed as argument, Rhythmbox creates as many new radio station entries as the 'pls' file contains as alternative URL for the stream. This adds needless clutter in the radio catalog of Rhythmbox, especially given how the new stations are nameless. The prefered method would be for Rhythmbox's own catalog to allow several URL for a single radio station. Also, Rhythmbox should prompt the user to give a name to the station whenever it adds a new one to its catalog. " Bye, Other information:
Unfortunately there is no real way of telling whether subsequent entries are alternate urls for the same station or different stations. I agree that prompting for a name when the PLS file doesn't have one is a good idea.
I've heard several people on IRC ask for handling as the bug suggests. And several other people on IRC, and a comment on bug 320336, ask for the opposite handling. I have no idea how we can resolve this.
Can't we safely assume that stations will have a seperate .pls per station? I've never seen one who set up multiple different stations, only alternative urls for the same stream.
(In reply to comment #1) > Unfortunately there is no real way of telling whether subsequent entries are > alternate urls for the same station or different stations. It really doesn't matter. The important thing to remember is that the URL of the playlist is the 'unique identifier' of the 'radio station'. Each entry in the Internet Radio list should refer to a *playlist* URL. Essentially what we're doing when we add an Internet Radio Station is 'subscribing to a remote *playlist*'. If the person providing the remote playlist makes a change to that playlist, I want to know about it. Think of the playlist in the same way you'd think of a DNS A record - you gotta look it up for each request if you want to know where the goods are. The way RB currently works, if I subscribe to SomaFM and they change their streaming server IPs a week later, I'd have some stale, useless entries in my station list. Users might come to the conclusion that RB is broken if enough of their entries get stale. Playing a radio station should refresh the playlist from the net, then start playing the first stream in the list. If that stream dies - or the user clicks 'Next' - RB should switch to the next entry in the playlist. Most of the time when Internet Radio playlists containing more than one entry, it's because the station has a cluster of servers streaming the same content. If one goes down, you move to the next stream in the list. This is far and away the most common case. Have a look at the playlists offered by shoutcast.com, di.fm, etc. UI-wise, it might be good to lose the "auto-subscribe" behaviour altogether. Let people listen to iradio playlists without subscribing to them and keep a transient 'recent streams' list (integrated with the current view). Let them subscribe within the RB interface as they listen, if they like.
The patch I just committed for bug 320336 improves rhythmbox's behaviour in this respect. Grouping the multiple stream URLs added when clicking on a playlist link in a web browser would be difficult and would require some fairly extensive changes, so it's probably not going to happen. Bug 334884 is similar, and has some discussion of what would be required to do this.
Just to throw another voice into the crowd, I would find some sort of grouping for radio stations particularly useful. Having a .pls file from shoutcast create 19 new radio stations isn't particularly useful when they all represent the same station.
A grouping system similar to Pidgin's grouping of multiple screennames would be best I think. I think this is a rather important issue to be cleared up in rhythmbox.
I think Comment #4 got it just right. Why store the different entries in the pls file when you can store the URL of the pls file it self?
That's what we do when we actually get the URL of the pls file. When the user clicks on a .pls URL in a web browser, though, we only get a path to a local copy of the file.
So what's needed is for Rhythmbox to be registered as the handler of .pls files in Firefox?
(In reply to comment #10) > So what's needed is for Rhythmbox to be registered as the handler of .pls files > in Firefox? No, it's already registered as that. See the upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=137339
*** Bug 524844 has been marked as a duplicate of this bug. ***
*** Bug 592711 has been marked as a duplicate of this bug. ***
i wrote a little "wrapper script" that handles .pls and .m3u playlists from firefox and passes it to rhythmbox in a way so RB will AUTOPLAY the stream. Just give it a try at my Website: http://www.awerner.homeip.net/doku.php?id=it-artikel:gnome-rhythmbox-autoplay-wrapper-script-for-internet-radio-shoutcast-streams PS: see english describtion down in the script itself. greetings Axel
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/105.