Sending again .... is this thing on? On 11-Feb-05, at 9:20 PM, oddsock wrote:> 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> 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.Okay, so this actually injects it into the stream as shoutcast metadata, not just into the server's admin interface? Someone just emailed me to say that this simply updates currently-playing data on the admin pages.> keep in mind that the shoutcast-metadata protocol is only used for MP3 > streams.For reasons discussed previously I, and a number of professional broadcasters, am married to straight MP3 and have to wait for Vorbis. Full support for this would serve me better than lots of support for Vorbis tagging. Karl is a god for coding this up.> 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.For the static YP variables (genre, url) I'd at least like to be able to modify these at runtime in the Icecast config file, which is as I seem to remember how Shoutcast behaves. Try finding my servers on the xiph.org yellow pages. :)> 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)....and I presume that when we update the song title using the method I specified above it causes Icecast to spark a GET to the xiph Yellow Pages to update song data, as well... correct?>> 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.I'd need an EPROM burner to modify my encoders, unfortunately. http://www.audioactive.com/support/manuals/aampegmanual.pdf All we're trying to do is get the maximum amount of data populated for both YP listings and for clients like WinAmp and iTunes. -Ian. _______________________________________________ Icecast mailing list Icecast@xiph.org http://lists.xiph.org/mailman/listinfo/icecast
At 08:24 AM 2/15/2005, you wrote:>Sending again .... is this thing on?sorry, meant to respond, been very busy of late....>On 11-Feb-05, at 9:20 PM, oddsock wrote: > >>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. > >Okay, so this actually injects it into the stream as shoutcast metadata, >not just into the server's admin interface? Someone just emailed me to >say that this simply updates currently-playing data on the admin pages.Currently, when you set the metadata via the server's admin interface, that metadata will then be injected into the outgoing stream (i.e. that sent to listeners) using the shoutcast metadata protocol (I'm only going to be talking about MP3 here). It does NOT just update the currently playing data. It USED to do this pre-2.2, but only for Vorbis streams...>>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. > >For the static YP variables (genre, url) I'd at least like to be able to >modify these at runtime in the Icecast config file, which is as ICurrently, we do not have a mechanism for specifying (or overriding) these parameters in the icecast config. I welcome you to post something to http://trac.xiph.org as an enhancement. Alternatively, in do_yp_add() line 344 of yp.c, you will find the following line : ret = snprintf (s, len, "action=add&sn=%s&genre=%s&cpswd=%s&desc=" "%s&url=%s&listenurl=%s&type=%s&stype=%s&b=%s&%s\r\n", yp->server_name, yp->server_genre, yp->cluster_password, yp->server_desc, yp->url, yp->listen_url, yp->server_type, yp->subtype, yp->bitrate, yp->audio_info); a simple hard coding of your parameters there will also suit your needs. Note doing it properly via config overrides takes a bit more work :)>seem to remember how Shoutcast behaves. Try finding my servers on the >xiph.org yellow pages. :) > >...and I presume that when we update the song title using the method I >specified above it causes Icecast to spark a GET to the xiph Yellow Pages >to update song data, as well... correct?Not sure, I'd have to look closer at the YP code..it used to, but Karl re-wrote how the YP communication was done with icecast. He may have pulled it out into a "periodic" update rather than an immediate trigger update. oddsock
On Tue, 2005-02-15 at 14:45, oddsock wrote:> >seem to remember how Shoutcast behaves. Try finding my servers on the > >xiph.org yellow pages. :) > > > >...and I presume that when we update the song title using the method I > >specified above it causes Icecast to spark a GET to the xiph Yellow Pages > >to update song data, as well... correct? > > Not sure, I'd have to look closer at the YP code..it used to, but Karl > re-wrote how the YP communication was done with icecast. He may have > pulled it out into a "periodic" update rather than an immediate trigger update.There is both, a periodic update (default 60 seconds, can be specified by the YP server) which is needed for refreshing entries and an immediate trigger (ie yp touch) when there are updates. karl.