ok, I apologise in advance if this is rubbish or contentious :-)

The Slim::Web:Pages.pm module uses Slim::Music::Info::getCurrentTitle() for the
current song in a playlist, but Slim::Music::Info::standardTitle() for the rest. 
(in 6b2)

For radio streams standardTitle returns the stream name (ie  (#1 - 802/16791)
Groove Salad: a nicely chilled pla... etc) and getCurrentTitle returns the
metadata for the song now playing on the stream.

So changing Slim::Web:Pages.pm around line 1049ish to just use standardTitle for
all tracks in the playlist does whats being suggested here.  

BUT.... I dunno what else that might break - I only use slimp3 and xmms as
players with the default web skin here. (I'm guessing there was a good reason
for using the different titles?).

Also, is there any reason why icy/shoutcast clients get sent the standardTitle
in the metadata from slimserver rather than the getCurrentTitle string? 

Changing line 1477 of Slim::Web:HTTP.pm to use getCurrentTitle displays the
current song title rather than the (boring) stream title on xmms when listening
to radio stations via slimserver. Much more useful, but again, I don't know what
impact that might have on other players.

regards,
Greg.

These both seem pretty good.  The first does keep the playlist items showing the
url, while leaving the now playing display to update.  The one downside is that
some streams will report the radio station callsign first, so the playlist would
update with the nice name instead of the song name.  I'm unsure which is the
best way to go since neither is perfect.  This seems to be the only side effect
that I have noticed. 

the other case, in HTTP.pm would see to only every affect http clients, so
really woudlnt' seem to have any ill effects for the main things that the server
has to do.  

That's what I get from my testing.  I'll leave it to SlimDevices to decide if it
should be put in.

Created attachment 632 [details]
patch for http.pm and now playing

here is the diff for the http.pm change mentioned.  seems to work nicely.  also
included is a diff to playlist.pm to get rid of a warning due to the now
playing display logic (since http doesn't have a display)

Created attachment 633 [details]
pages.pm change, for later

and in case this might be of use later, the diff for pages,pm

Kevin, thanks for your testing and feedback, but I'm not following the bit about
the 'one downside' with the pages.pm patch. 

Sure, the now playing section of the web interface may *initially* report the
stream "nice" name, and indeed this may be streamed to the player too, but here
its then always switched to the current song title a short time later. Plus the
playlist entry has always remained unchanged. 

What I haven't had time to determine yet is if radio stream titles work this way
by design or if its a happy accident.

regards,
Greg.

Well, in the playlist listing, I was using a rather ugly url.  If you click on
one of the items in the playlist, it would immediately update to the station
name, which did look better.  Its only momentary, but I felt it was worth
mentioning.  With the patch, it will stay as the url. Just becuase I mention it
as a downside, doesn't mean its  HUGE annoyance.  However, it must still be
mentioned, because somewhere along the line, it is quite possible that someone
will suddenly decide it IS a huge annoyance, and scream about it in the forum,
etc, etc. ;)

Thanks for the clarifcation, I don't see the momentary name change here but that
may be down to timings with page refreshes and the stream meta-data updating the
title info.

Having urls in the playlist frame is naff, but I suspect that may be an issue
with the ShoutCast browser code. The RadioIO code for example doesn't do that.

Adding "Slim::Music::Info::setTitle($infoUrl, $title) if $create;" after line
197 in Slim::Player::Protocols::HTTP.pm (version 3527) sets the title in the
playlist frame to the icy-name sent when the remote stream is opened. (with the
other patches applied of course).

This is more readable than a playlist url, but it changes the displayed data for
all radio stations. Thats not a bad thing though (in my opinion).

Whats probably best is if the radio modules could make the stream ident
(icy-name or similar), the latest stream meta-data (if any), and the url all
available to the rest of the code in a consistent manner.

regards,
Greg.

committed HTTP.pm part of this patch to the trunk (6.2 nightly builds) at change
3788

Dean, 
any thoughts on the patch to Pages.pm for this?  I'm not sure what the desired
info should be in the playlist for streams.  It might be more consistent to
stick with the url (standardTitle), but the currentTitle is nicer reading, even
if it might contain old song metadata.  Seems to me that this can either be
patched (which does seem ok, no breaks that I saw) or left as is and closed.

I wonder if we should show both the station information AND the current song information if they both 
exist and are different.

The current song is shown in the status_header, the url would be shown in the
playlist section.  The station information meta data isn't always sent, and is
often rapidly followed by the song data.  Currently, if the timing is right, the
playlist is sometimes updated in time to have the station name, and not the song
title. I have no idea how tricky it would be to catch and store the station name
and recognise when its not actually a station name.

KDF: should we just go ahead with this patch?

I think its worth giving it a shot. See if anyone out there notices or has a
problem with it :)

committed the change to pages.pm to trunk at change 4242, for Sep 13 build