similar to: Updating MetaData at the Relay

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

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?

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=/

Howdy Folks: Is there a way in v2.4.2 to include a ?StreamUrl=? field in the stream metadata as well as ?StreamTitle=?? It appears that the administrative interface only populates StreamTitle. For example: http://server.example.com:8000/admin/metadata?mount=MyMount&mode=updinfo&song=MySong will insert only ?StreamTitle=MySong?;. Googling around has brought up some possible

When "Icy-MetaData: 1" is in the HTTP request to the server, that indicates that the client wants to receive meta data inlined with the mp3 data stream. The metadata interval is reported by the server via the "icy-metaint" header in the response stream. Such data looks like the following within the mp3 stream StreamTitle='Ozzy Osbourne - Crazy

Like any other major radio station we output our music from automation software via analog audio through a mix board in a studio, where we insert other stuff like live DeeJays, etc. only to have that stream re-encoded by hardware MP3 encoders for distribution to our network of IceCast servers. The chain of song information gets broken as soon as we output from the Automation software,

Hi, What's the URL format for Icecast2 metadata updates? I thought this info would be in the source docs somewhere but apparently not. I've got a client which lacks Icecast2 native metadata updates and even for a C hack like myself, this should be pretty easy to add given the shoutcast code that already exists in there. I just need the format. Geoff. -- Geoff Shang

Hi everyone, I would like to update metadata by using this request: http://server:port/admin/metadata?mount=/foo.ogg&action=updinfo&song=New+Metadata, but when I send the request, icecast returns an error: "Missing parameter" and metadata doesn't change. This is error.log: [2004-01-21 12:20:32] DBUG

Jason wrote: > http://IP:PORT/admin/metadata?mount=/MOUNTPOINT&mode=updinfo&song=METADATAYOUWANTTOUPDATE Wouldn't that require the admin password? Surely there's a way of doing it which only requires the source password, heck there must be since streamTranscoder is sending in metadata updates nicely without needing the admin pw. Geoff.

Right... I understand how the stream works and we have no confusion at all then. So I need to create a script to re-inject MP3 Metadata from my handy-dandy XML file (when it changes) which is easily done if, as you say, there're a few variables that the admin.cgi can listen for (of course Icecast has no admin.cgi) The info you've provided for Shoutcast is useful and you allude to

I meant to send the message to the list but the default is to reply to the sender, which I find a big hassle. I know, I should being using a proper email client and not Outlook Express. > Now that 2.2.0 is out, we can update metadata on-the-fly. http://server.ip:port/admin?&mode=updinfo&song=ACDC-Back_In_Black This syntax is supported but it only shows up on the Icecast2 server

Hi team, Please accent my apologies if this is NOT the place/distro list to be raising this. I had major dramas with the standard forum - registration and decided this may be a better route. My current instance icecast server has been built with --with-curl --with-openssl options as outlined within this post: https://weekly-geekly.github.io/articles/350236/index.html and the build version is

Greeting all -- I'm having some problems setting up multiple streams with iceS, for example, a hi-bandwidth and lo-bandwidth stream of the same audio. Could someone post a config that works in this case? thanks .oOo.oOo.o..o.oOo.oOo. Ben Wilson admin -- thelocust.org ben@thelocust.org 'OoO'OoO'O''O'OoO'OoO' --- >8 ---- List archives:

I thought the YP code was going to be fixed to use less resources so it could be used with other stream formats. It seems to be taking a long time. As it is now, Icecast2 is not a good solution for those wanting to be on a popular directory. I am forced to recommend using Shoutcast to my clients so they can get onto a popular directory. I would prefer to recommend Icecast2. Ross Levis.

ices.conf: <Public>1</Public> <!-- The name of you stream, not the name of the song! --> <Name>Poohba's Urban Sounds</Name> <!-- Genre of your stream, be it rock or pop or whatever --> <Genre>RnB</Genre> icecast.xml <directory> <yp-url-timeout>15</yp-url-timeout>

On Wed, Jun 25, 2003 at 03:33:25PM +1000, Michael Smith wrote: > > Is the metadata relayed to connecting clients. i.e. take a client that > supports shoutcast-style metadata, like winamp (and probably most others). > Connect as a listener to the relay. Do you get metadata? You should. If you > don't, the metadata relaying could have been broken (I think this is >

I can understand wanting to boost the adoption of Xiph codecs, but I think restricting the directory to vorbis streams only will not help this endeavour. I can imagine it will just piss a lot of people, including myself, and give Xiph a bad name. I get very few listeners of my AAC+ stream now since this occured. The restriction is not an insentive to switch to Ogg Vorbis at all. The incentive

On Wed, Jun 25, 2003 at 11:34:07AM +1000, Michael Smith wrote: > > > 2) Should relay icy/x-audiocast stream metadata when connecting to > > icecast1/shoutcast/etc so that this information is available to YP > > Eh? It does. I even tested that with someone's shoutcast stream. It works. > Just add >

Yeah it is a tad gross but here is my first (and probably only) attempt: ---------------- 8< ---------------- #!/bin/bash pipe=/tmp/testpipe trap "rm -f $pipe" EXIT if [[ ! -p $pipe ]]; then mkfifo $pipe fi mplayer -slave -playlist "http://my.icecast.stream/music" > /tmp/testpipe 2> /dev/null & while true do if read line <$pipe; then

On Wed, Jun 25, 2003 at 04:27:58PM +1000, Michael Smith wrote: > > > > notice that, with exception of the last, they're all ice-* not icy-*... > > prehaps this is incompatable with the way most players operate to get > > stream data? Is this a typo? > > No. This is deliberate. There could be a bug in the code that takes these > headers and puts bits of them