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 > unlikely, though - that code hasn't been changed lately AFAIK)Or connect via telnet and see what's really going on ;-) HTTP/1.0 200 OK Content-Type: audio/mpeg icy-br: 64 icy-genre: Talk icy-metaint: 8192 icy-name: Enemy Combatant Radio icy-notice1: <BR>This stream requires Winamp<BR> icy-notice2: SHOUTcast Distributed Network Audio Server/FreeBSD4 v1.9.2<BR> icy-pub: 1 icy-url: http://sf.indymedia.org/ Server: Icecast 2.0-alpha2/cvs Yes, it copies over the icy headers exactly as-is... Now what's interesting, prehaps this is a bug??? this is the headers as given by a Icecast2 origionated stream: HTTP/1.0 200 OK Content-Type: audio/mpeg ice-bitrate: 16 ice-description: SF Indymedia ice-genre: Talk ice-name: Enemy Combatant Radio ice-public: 1 ice-url: http://sf.indymedia.org/ icy-metaint: 16000 Server: Icecast 2.0-alpha2/cvs 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?> I couldn't say whether or not this metadata is propogated to the stats core > (and I think from there to the YP update stuff?). Maybe that's what is > missing.I don't know because I don't have a shoutcast server in front of me to compair it's YP with ours, but yes, Icecast2 is not sending this information to YP servers. I would very much prefer if it were to send it in Icecast2 YP style and not Shoutcast (ICY) style, prehaps running the field names through a translation table? Just the three are really needed, tho song info and bitrate are needed too, but the stream name, description, and genre are musts... the associated URL would be good too, the listenurl is provided by Icecast2 itself, and the rest of the information isnt really that important.> > What's the alternative to <relay-shoutcast-metadata> if you want to > > relay Icecast2 metadata vs shoutcast metadata, so I can fix the > > non-shoutcast entries? Do you use this for icecast1 servers as well? > > This option turns on relaying of shoutcast-protocol mp3 metadata. icecast 1.x > optionally uses this (it also has a second, UDP based, way of doing metadata. > Few clients support it, icecast2 doesn't support it), and icecast2 uses it if > it's using metadata at all.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? -------------- 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/f8d81d04/part.pgp
On Wednesday 25 June 2003 15:55, Arc wrote:> 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 unlikely, though - that code hasn't been changed lately > > AFAIK) > > Or connect via telnet and see what's really going on ;-) ><snip headers>> Yes, it copies over the icy headers exactly as-is...Right. This is why I said "try this with a real client". mp3 metadata is inline, not in the HTTP headers.> > Now what's interesting, prehaps this is a bug??? this is the headers as > given by a Icecast2 origionated stream: > > HTTP/1.0 200 OK > Content-Type: audio/mpeg > ice-bitrate: 16 > ice-description: SF Indymedia > ice-genre: Talk > ice-name: Enemy Combatant Radio > ice-public: 1 > ice-url: http://sf.indymedia.org/ > icy-metaint: 16000 > Server: Icecast 2.0-alpha2/cvs > > 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.> > > I couldn't say whether or not this metadata is propogated to the stats > > core (and I think from there to the YP update stuff?). Maybe that's what > > is missing. > > I don't know because I don't have a shoutcast server in front of me to > compair it's YP with ours, but yes, Icecast2 is not sending this > information to YP servers. I would very much prefer if it were to send > it in Icecast2 YP style and not Shoutcast (ICY) style, prehaps running > the field names through a translation table? Just the three are really > needed, tho song info and bitrate are needed too, but the stream name, > description, and genre are musts... the associated URL would be good > too, the listenurl is provided by Icecast2 itself, and the rest of the > information isnt really that important.The YP info is distinct from the stream metadata, you're confusing the two here. YP info _should_ include information from the stream metadata (it probably doesn't at the moment due to bugs).> 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). 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. 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.
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