[icecast-dev] Icecast's YP bugs

[Michael Smith]

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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.