Bug 6482 - When playing a radio station, the user friendly name is used, then lost
: When playing a radio station, the user friendly name is used, then lost
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Streaming To SlimServer
: 7.0
: Macintosh Other
: P3 normal (vote)
: ---
Assigned To: Michael Herger
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-28 08:50 UTC by Blackketter Dean
Modified: 2008-12-18 11:12 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments
Web interface screenshot (103.87 KB, image/png)
2008-01-27 16:24 UTC, Blackketter Dean
Details
Jive screenshot for same song (46.03 KB, image/png)
2008-01-27 16:25 UTC, Blackketter Dean
Details
add more meta data to internet radio songinfo page (30.85 KB, image/png)
2008-01-28 03:51 UTC, Michael Herger
Details
detailed title/artist information (36.91 KB, image/png)
2008-01-28 03:52 UTC, Michael Herger
Details
add new 'N' tag for remote stream title (3.23 KB, patch)
2008-02-04 03:41 UTC, Michael Herger
Details | Diff
web UI with patch applied (35.67 KB, image/jpeg)
2008-02-04 03:48 UTC, Michael Herger
Details
"user friendly" station name in collapsed view (18.21 KB, image/jpeg)
2008-02-04 10:23 UTC, Michael Herger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Blackketter Dean 2007-12-28 08:50:01 UTC
When I choose a station from one of our content providers or a favorite, when you play the immediate feedback on Jive or SB is 

Now Playing
<station name>

But that station name is lost when you get to the now playing playlist.  Would it be possible to associate that station name with the URL so that it appears correctly in the playlist?
Comment 1 Blackketter Dean 2007-12-28 08:54:01 UTC
Hm, this is stranger than I thought.  Stations picked from the RadioIO plugin lose this information, but ones from Picks do not.

Comment 2 Blackketter Dean 2008-01-20 12:12:46 UTC
Andy: can this be addressed for 7.0?

Comment 3 Andy Grundman 2008-01-20 12:32:40 UTC
For stations that return their own title in the HTTP headers, we use that title as the stream title.  Don't think this is a bug.
Comment 4 Blackketter Dean 2008-01-21 09:24:02 UTC
dean to reproduce
Comment 5 Blackketter Dean 2008-01-27 16:24:19 UTC
Created attachment 2737 [details]
Web interface screenshot

This is really inconsistent.  Note that the Now playing has the song title, and artist (cool!) and the original Picks title "Alt | Radio Paradies".  The song info page, though, is using another station description, but is missing the other stuff (artist, album, Picks name, and suprisingly, the URL).
Comment 6 Blackketter Dean 2008-01-27 16:25:31 UTC
Created attachment 2738 [details]
Jive screenshot for same song

Here we the station name first and the song title and artist second and third.
Comment 7 Blackketter Dean 2008-01-27 16:27:19 UTC
Finally, the Squeezebox showed the song title and the artist name, but not the station name.

We should be showing this all consistently:

Song Title
Artist
Station Name

In all UIs, with all this information (and more) in the song info screens.
Comment 8 Michael Herger 2008-01-28 03:13:47 UTC
Songinfo vs. player display/control panel/Jive: I assume that the information displayed in the updating UI elements are taken from the stream, while the songinfo page is built based on the XML/OPML file downloaded. As this page is also used when browsing radio stations not being played, we can't rely on having accurate data at any time the page is displayed. But we could probably add some code to XMLBrowser to include the additionl information if available.

As for the information: I doubt it would be reasonable displaying the station name on the SB's display. Some of the station names are _huge_, which would result in too much scrolling to be useful. Let's take eg. your example, Radio Paradise. The full station name given when browsing Shoutcast (you selected it from Picks) is "Radio Paradise - DJ-mixed modern & classic rock, world, electronica & more - info: radioparadise.com ". Scrolling this together with the current song information renders the whole display useless.

I'd love to see it available in a separate tag, though, which could be used with the MusicInfoSCR screensaver.
Comment 9 Michael Herger 2008-01-28 03:15:19 UTC
oops, I was wrong... the Songinfo page is yet another variation, it's not the same as XMLBrowser...
Comment 10 Michael Herger 2008-01-28 03:51:56 UTC
Created attachment 2742 [details]
add more meta data to internet radio songinfo page

change 16825 - RadioIO doesn't provide distinct title/artist information, thus it's a one liner with both of them.
Comment 11 Michael Herger 2008-01-28 03:52:49 UTC
Created attachment 2743 [details]
detailed title/artist information

Some other stations provide title/artist separately (eg. Radio Paradise)
Comment 12 Andy Grundman 2008-01-28 07:14:03 UTC
Radio metadata should be parsed into artist/title if it contains one " - ".
Comment 13 Michael Herger 2008-01-28 07:17:43 UTC
Are you assuming it's always ARTIST - TITLE? Or is this kind of standard?
Comment 14 Andy Grundman 2008-01-28 07:24:27 UTC
It seems to be the convention.  I'm still not clear on what the issue is here.
Comment 15 Michael Herger 2008-01-28 07:49:29 UTC
We're doing this parsing in Slim::Player::Protocols::HTTP for the default http stream, but not RadioIO & some others. We should probably do this for all of them. Would fix a few instances of the same code I checked in today where this is done after the call to getMetadataFor().
Comment 16 Michael Herger 2008-01-28 08:08:43 UTC
change 16832 - moving the artist/title parsing to include it with RadioIO and LMA streams
Comment 17 Andy Grundman 2008-01-28 08:37:33 UTC
Oops, you're right.  It's not really appropriate for LMA though.  It's probably not possible to determine LMA metadata properly.
Comment 18 Michael Herger 2008-01-28 09:59:24 UTC
change 16839 - fix title parsing for LMA
Comment 19 Michael Herger 2008-01-28 11:53:15 UTC
Dean - could you please give this another try? As mentioned in comment #8 I would _not_ add the station name to the player interface (at least not by default).
Comment 20 Blackketter Dean 2008-02-01 13:15:29 UTC
So, it's still not consistent.    The now playing section on the the web interface and the now playing screen on Jive are still different.

Let's make the web the same as the Jive UI:

<b>Alt | radio Paradise</b>
Title
Artist

Then in the song info screen, the title of the stations should be "Alt | radio paradise", with song title and artist, as well as provided station name "Radio Paradise - DJ-mixed modern & classic rock, world, electronica & more - info: radioparadise.com" as supporting content.  Both for web and jive song info screens.
Comment 21 Michael Herger 2008-02-01 14:46:15 UTC
Argh... this is hardcoded in _addJiveSong - I'll have to come up with some similar "fix" for the web interface. Problem is that this value (station name) IMHO isn't returned by a normal CLI command, but only by the Jive specific menu:xyz version.
Comment 22 Andy Grundman 2008-02-02 08:01:55 UTC
A station only ever has one "title" value, so this won't really be possible.
Comment 23 Blackketter Dean 2008-02-02 08:23:07 UTC
So how are both titles shown here?

https://bugs-archive.lyrion.org/attachment.cgi?id=2737
Comment 24 Andy Grundman 2008-02-02 08:26:46 UTC
Probably a caching issue, the playlist has not updated to the latest title.
Comment 25 Michael Herger 2008-02-04 03:41:46 UTC
Created attachment 2811 [details]
add new 'N' tag for remote stream title

As Andy says there can only be one title. _addJiveSong is concatenating the title and station information into one string. This can't be done in the web UI unless we're adding one more tag.

This patch does so, adding 'N' as the remote stream title tag, plus the client side parsing.
Comment 26 Michael Herger 2008-02-04 03:48:41 UTC
Created attachment 2812 [details]
web UI with patch applied

I'm not sure we want this. Though it's consistent with the Jive UI, I think it's wrong in the web UI. As the web UI puts some stress on the first line (whatever it is), the station name imho gets too much attention compared to the title. On Jive the same behaviour isn't this obviously wrong, was we're not reserving additional space for it, but only putting that line in bold letters.

Oh, just noticed, that the name in this case even is too long for two lines - the link goes lost. This could happen with many streams which add absurd long and odd station names. Again, this is less obvious on Jive, as it's scrolling, not wrapping.
Comment 27 Michael Herger 2008-02-04 10:16:45 UTC
change 17176 - checked the above patch in
Comment 28 Michael Herger 2008-02-04 10:22:23 UTC
Crap... what about the collapsed view in the web UI? In this case we should display the current_title, I assume?
Comment 29 Michael Herger 2008-02-04 10:23:08 UTC
Created attachment 2814 [details]
"user friendly" station name in collapsed view

This should rather be consistent with the SB classic UI?
Comment 30 Andy Grundman 2008-02-04 11:47:21 UTC
There is still a caching issue here, the web and CLI sometimes don't update to the proper title after it has been changed.  Probably a simple matter of updating a timestamp when the title is changed.  I'll look into it.
Comment 31 Andy Grundman 2008-02-04 11:49:42 UTC
A good example of the title cache issue is Lounging Sound.

Picks title: "Lounging Sound"
Title in their M3U playlist (http://www.loungingsound.com/listen.m3u): "Lounging Sound [HiFi]"
Title in stream header: "Lounging Sound"

Sometimes you will see the [HiFi] title when you should never see this.
Comment 32 Andy Grundman 2008-02-04 13:29:30 UTC
The title cache issue appears to be fixed in change 17189.
Comment 33 Michael Herger 2008-02-04 14:09:56 UTC
collapsed view fixed in change 17197
Comment 34 Chris Owens 2008-03-07 09:04:31 UTC
This bug is being closed since it was resolved for a version which is now released!  Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html

If you are still seeing this bug, please re-open it and we will consider it for a future release.