At 05:31 PM 6/25/2003 +1000, you wrote:> > I'm not concerned with how players see anything right now, tho that is a > > concern I guess. I'm concerned with getting the vitals - the stream > > name, genre, and description, to be relayed to a YP server when Icecast2 > > is relaying a Shoutcast stream. Currently it does not, this is missing > > functionality that needs to be provided because currently it's "breaking > > protocol" (as defined by Oddsock's Icecast2 YP document) by sending add > > requests without a stream name. go back a few emails, see where this > > came from.. one of three bugs in Icecast's YP support. A fairly minor > > one compaired to the memory leak bug, but still very problematic for us. > >Ok. I guess I don't see these as 'vitals' - which is why we were talking >about >different things. > >Probably a bug in the stats header parser or the YP code. Shouldn't be >hard to >fix (I can't - don't have cvs access from work, don't have internet access >from home, currently - but there are several developers who know how the >stats stuff works) > >Mikethe problem is with the parsing of the source, it is looking for ice-* and not the icy-* in the source header. The question is, do we want to support the icy headers from shoutcast ? I suppose we probably should, but it's a bit irritating having to put shoutcast compatibility code in icecast..... oddsock <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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 into the stats core, though. Maybe it only > checks for the ice-* variants, not the icy-* (shoutcast) ones.But what about the header data getting relayed correctly?> > Is there harm in having it turned on for 1) MP3 streams which origionate > > from a Icecast2 server, and 2) for Ogg streams origionating from a > > Icecast2 server? Should it be on or off, in other words, for best > > preformance? > > 1) No, this is the intended use (if the mp3 stream has metadata). > 2) No, it will have no effect in that case at all. > > For best performance it should always be turned off, though. The mp3 metadata > support is NOT high performance (due to bad protocol design by the shoutcast > people, it can't be, unless we introduce large buffering overheads, thus > drastically increasing latency).I don't understand... this option turns on any form of MP3 metadata being included in the stream.. so, is this right, that if this were to be turned off then XMMS would no longer get updates on the current song title/etc.. information such as would be provided by an ID3 tag? This is nessesary information.. just the "shoutcast" part of the tag is confusing, why not say "relay-mp3-metadata" instead?> Hrmm... Suddenly, an idea strikes me. Are you talking about the in-stream > metadata at all? (that's what I was talking about). This is what comes up in > the directories as 'now playing' information, and is sent to clients that > support it. > > If you're just talking about the header info (stream name, description, etc.), > then the relay-shoutcast-metadata option won't have any effect. If that > doesn't work, it could be a minor bug in how these headers are parsed and > sent down to the stats core.I'm not concerned with how players see anything right now, tho that is a concern I guess. I'm concerned with getting the vitals - the stream name, genre, and description, to be relayed to a YP server when Icecast2 is relaying a Shoutcast stream. Currently it does not, this is missing functionality that needs to be provided because currently it's "breaking protocol" (as defined by Oddsock's Icecast2 YP document) by sending add requests without a stream name. go back a few emails, see where this came from.. one of three bugs in Icecast's YP support. A fairly minor one compaired to the memory leak bug, but still very problematic for us. <p> -------------- next part -------------- A non-text attachment was scrubbed... Name: part Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20030625/620e1d5d/part.pgp
> I don't understand... this option turns on any form of MP3 metadata > being included in the stream.. so, is this right, that if this were to > be turned off then XMMS would no longer get updates on the current song > title/etc.. information such as would be provided by an ID3 tag?mp3 streaming as done by shoutcast and icecast does not (and cannot) use ID3 tags. The source streamer might use ID3 tags in the original material to generate the metadata, but icecast never sees that.> > This is nessesary information.. just the "shoutcast" part of the tag is > confusing, why not say "relay-mp3-metadata" instead?It's a shoutcast protocol. This option turns on using this protocol for relays. It won't turn on any other mp3 metadata protocols.> > I'm not concerned with how players see anything right now, tho that is a > concern I guess. I'm concerned with getting the vitals - the stream > name, genre, and description, to be relayed to a YP server when Icecast2 > is relaying a Shoutcast stream. Currently it does not, this is missing > functionality that needs to be provided because currently it's "breaking > protocol" (as defined by Oddsock's Icecast2 YP document) by sending add > requests without a stream name. go back a few emails, see where this > came from.. one of three bugs in Icecast's YP support. A fairly minor > one compaired to the memory leak bug, but still very problematic for us.Ok. I guess I don't see these as 'vitals' - which is why we were talking about different things. Probably a bug in the stats header parser or the YP code. Shouldn't be hard to fix (I can't - don't have cvs access from work, don't have internet access from home, currently - but there are several developers who know how the stats stuff works) Mike --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.