Think I answered my own question really. The display in iTunes, for example, is swapping between what in status.xsl would be Stream Title and Current Song. If Song is updated like so: http://admin:password@myserver.pulverradio.com:8000/admin/metadata? mount=/high.mp3&mode=updinfo&song=ACDC+Back%20In%20Black ...then what exactly is the verbage to update StreamTitle? http://admin:password@myserver.pulverradio.com:8000/admin/metadata? mount=/high.mp3&mode=updinfo&StreamTitle=PulverRadio ...doesn't work. My (potentially misguided) belief is that the client downloads/receives the latter attribute once, on initially connecting to the relay. KH and I have been playing with a branch he built that lets you configure all that stuff in the icecast.xml file however it's not making it into the stream. -Ian. On 5-May-05, at 12:04 PM, Tristan Horn wrote:> (replying privately as I'm not sure this is too useful) > > On Thu, May 05, 2005 at 10:28:19AM -0700, Ian Andrew Bell wrote: >> >> So when I listen to other stations that stream using >> icecast/shoutcast and ices/shoutcast source the player is swapping >> and/or scrolling between what looks like the name of the station and >> the currently playing song. This is what I want to achieve with our >> efforts. This means that somehow we have to tell the player, via the >> relay servers, BOTH the static station information AND the currently >> playing track. >> >> The question is, how exactly do they arrive at this information? > > Swapping and scrolling are two completely different things. :) Do you > have an example of a station that does this? > > Not sure if it helps, but I believe the metadata interval is usually > set to 8192 bytes, so for a 128k stream, that's twice per second that > you could theoretically update the metadata. > > Tris >
On Thu, 2005-05-05 at 20:17, Ian Andrew Bell wrote:> Think I answered my own question really. > > The display in iTunes, for example, is swapping between what in > status.xsl would be Stream Title and Current Song. > > > If Song is updated like so: > http://admin:password@myserver.pulverradio.com:8000/admin/metadata? > mount=/high.mp3&mode=updinfo&song=ACDC+Back%20In%20Black > > ...then what exactly is the verbage to update StreamTitle? > > http://admin:password@myserver.pulverradio.com:8000/admin/metadata? > mount=/high.mp3&mode=updinfo&StreamTitle=PulverRadio > > ...doesn't work.The "StreamTitle" is not part of the admin request you send, it's part of the metadata inserted into the stream.> My (potentially misguided) belief is that the client downloads/receives > the latter attribute once, on initially connecting to the relay. > > KH and I have been playing with a branch he built that lets you > configure all that stuff in the icecast.xml file however it's not > making it into the stream.AFAIK what you see in the player is made from a HTTP-type header sent to the client at connection time and any metadata that may be sent midstream. The stream override settings you mention don't affect the HTTP-style headers sent to the listener (whether they should and if so, how best to do that is another matter) but in-line metadata will be sent provided the metadata has been asked for (metadata is an add-on for mp3 streams) karl.
On 5-May-05, at 12:52 PM, Karl Heyes wrote:>> My (potentially misguided) belief is that the client >> downloads/receives >> the latter attribute once, on initially connecting to the relay. >> >> KH and I have been playing with a branch he built that lets you >> configure all that stuff in the icecast.xml file however it's not >> making it into the stream. > > AFAIK what you see in the player is made from a HTTP-type header sent > to > the client at connection time and any metadata that may be sent > midstream. The stream override settings you mention don't affect the > HTTP-style headers sent to the listener (whether they should and if so, > how best to do that is another matter) but in-line metadata will be > sent > provided the metadata has been asked for (metadata is an add-on for mp3 > streams)Let's face it -- what's going to make us all successful as streamers is appearing nicely in client apps. This is what I'm shooting for, as well. Right now PulverRadio looks like ass in WinAmp and iTunes, whereas stations streaming via other means are great. That's why I'm investing in dumping the SongData back into the stream (which works very well BTW!). The name of my mountpoint that gets listed by iTunes (in its index) in the "Song Name" field, and presumably the Stream field when/if it's listed in their Kerbango directory, is the name of my mountpoint: "high.mp3" or "low.mp3". This sucks. This hardly has the appeal of, say: "Virgin Radio UK" or "Indie Pop Rocks!". You can force this data by putting it into the .PLS file like so: [playlist] File1=http://radio.pulverradio.com/high.mp3 Title1=PulverRadio - Raw Rock Radio - 128kbps Length1=-1 NumberOfEntries=1 Version=2 ...and this works pretty well. To my knowledge the .M3U format has no such capability, though you might be able to use it like so: #EXTM3U #EXTINF:PulverRadio - Raw Rock Radio - 128K http://radio.pulverradio.com/high.mp3 I also have tried creating a friendly, descriptive mountpoint name which could appear in the player like so: /PulverRadio%20%2D%20Raw%20Rock%20Radio%20%2D%20128K This would be expected to appear in iTunes / WinAmp as: "PulverRadio - Raw Rock Radio - 128K" ...but this makes Icecast VERY unhappy. Returns a 404. So the questions are: A) What is the format of the metadata-on-connect that is expected by most clients? B) As is my usual question, how do we set this data where the broadcaster isn't using ices? C) If there is no such format, maybe this is the time to define a defacto standard and hope it sticks? If C) is a valid interest then this would be an opportunity to send a whole plethora of stuff with the stream, including ID3 tags for both the stream itself and each song within it. There's probably no reason not to be ambitious in this regard. -Ian.