[Icecast] Updating MetaData at the Relay

[oddsock]

At 10:21 PM 2/11/2005, you wrote:
>Now that 2.2.0 is out, we can update metadata on-the-fly.  At
>pulverradio.com we are working on an injector that takes the song info
>from our broadcast automation software and dumps it in (thanks guys for
>the help).  I realize that we can inject the song info like so:
>
>http://server.ip:port/admin/metadata?mount=/ 
>mountpoint&mode=updinfo&song=ACDC+Back+In+Black
>
>
>.... but are there other attributes, such as Genre, URL, etc. that we
>can input at this point?

no...at the moment, only "song" is supported.  All other stream info 
details (URL, Genre, etc) is not currently update-able via the admin 
interface.  The must be supplied by the source client on connect.

>I still can't find a definitive spec (not anyone on this list's fault)
>on what the shoutcast-metadata-protocol even allows, let alone which
>verbage is supported by IceCast.

keep in mind that the shoutcast-metadata protocol is only used for MP3 
streams.  Ogg Vorbis streams have an entirely different mechanism for 
dealing with metadata.  The metadata in vorbis streams is actually 
contained within the vorbis header.  This is actually why we initially 
didn't support the updating of this info via the admin interface.  Since 
doing so would require icecast to be able to rebuild the ogg vorbis 
bitstream in order to insert new metadata into the vorbis 
header.  Thankfully, Karl's done this work, and it works very well.  So 
technically we'd should be able to make arbitrary updates to vorbis comment 
fields (where the metadata is stored) via the admin interface (although 
this hasn't been done currently)...That still requires client players to 
display these fields in a meaningful way.  This is tricky as the vorbis 
comment fields are essentially free-form in nature with no set spec.

>Could it be as simple as:
>
>http://server.ip:port/admin/metadata?mount=/ 
>mountpoint&mode=updinfo&song=ACDC+Back+In+Black&genre=Rock&url=www.pulve 
>rradio.com

back to your question about shoutcast-metadata, the metadata protocol only 
supports two fields StreamTitle and StreamUrl.  Virtually ALL players (with 
the exception of winamp) ignore StreamUrl.  Winamp will use this 
information in the event that you actually open the winamp mini-browser 
while listening to a stream, it will open to the default page of the 
StreamUrl (or at least, that was the way it used to work).  So, for 
shoutcast-metadata, you really only have StreamTitle (which is usually just 
the song title).   This is actually, why the admin/metadata call only takes 
"song", and it was created back when we only supported updates for mp3 
streams.  Now, one could aruge that you should also be able to update the 
genre and maybe the url, but since these fields are used mainly for YP 
listing, they tend not to be fields that people want to update.  Although, 
I'm sure someone could find a good reason, I couldn't at the time, and 
therefore didn't make these fields update-able.  It's also important to 
understand that since these fields are used by the YP, you need to figure 
out what fields the YP will support updating.  From 
http://www.icecast.org/spec.php you can see that there is a limited number 
of update-able fields (song title, listeners, max_listeners, various 
listening times, and server type - of which only the dir.xiph.org supports 
a few (song and server type).


>The reason this is relevant is our dumb encoders just spew out MP3
>streams with no metadata at all.  It would be nice to be able to add
>cursory stuff so that we get listed properly on the XIPH yellow pages,
>etc.  Also, since we're using flaky DNS-based load balancing on our
>streaming network it'd be nice for all of my servers to masquerade as
>"radio.pulverradio.com" even though their actual hostname might be
>something completely different.

well, your encoders can't be *that* dumb as they probably support some 
level of HTTP authentication (unless they are connecting in 
shoutcast-compat mode), so all you need to do is add a few request headers 
when connecting the encoder, and you'll be properly listed.  And 
masquerading the listen url is not support, but easy enough to do with a 
simple hard-code modification.

hope this helped...

oddsock