[icecast-dev] bug report w.r.t. streaming of metadata in icecast

Brendan Cully brendan at icecast.org
Fri Aug 10 15:06:14 PDT 2001

On Thursday, 09 August 2001 at 18:08, Richard Fromm wrote:
> On Tue, 7 Aug 2001, Richard Fromm wrote:
> > to clarify, the behavior that i saw was that most of the time the title
> > streaming appeared in the client, but sometimes it did not.
> i think i've nailed this down.  the problem is if the icecast server
> starts in the middle of a song already being sourced to it.  (which you
> can get by starting icecast, start ices, then shutdown and restart icecast
> and ices won't complain if a small amount of time passes)

Ok, that's an ices bug. Ices should make sure to resend the metadata
if it has to reconnect. I'll fix that soon.

> one related question -- is there any easy way to find where the metadata
> gets inserted into the stream, or do i basically have to continually parse
> the stream if i want to extract that info?  i'm seeing chunks of 4096
> bytes, and the metadata gets added at the end of some chunk.  but this
> doesn't necessarily correspond to a boundary between mp3 frames.  given an
> mp3 stream, once i found a frame boundary it's easy to keep finding those
> boundaries.  but i don't know how to arbitrarily find icecast chunk
> boundaries if there's no delineating information.

The server returns an icy-metaint header which tells where the info
will be inserted. If, say, it's 4096 then you'll find the metadata
after every 4096 bytes of MP3 data. Unfortunately it does not position
itself on frame boundaries.


--- >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.

More information about the Icecast-dev mailing list