Icecast dev - Aug 2004 - bug report w.r.t. streaming of metadata in icecast

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.

-Brendan

--- >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 Tue, 7 Aug 2001, Brendan Cully wrote:
> On Tuesday, 07 August 2001 at 12:56, Richard Fromm wrote:
> > i believe there is a bug in the following line in
write_chunk_with_metadata()
> > in source.c.  here is the original:
> > 
> > 		if (source->info.udpseqnr == clicon->food.client->udpseqnr)
{
> > 
> > and here is the change:
> > 
> > 		if (clicon->food.client->use_udp &&
source->info.udpseqnr == clicon->food.client->udpseqnr) {
> 
> It's not a bug, the variable is just badly named. I know because I
> made the same mistake at first.
could you provide some more info on what client_t.use_udp and
client_t.udpseqnr are for, if not UDP sequence numbers?  my suspicion that
the if clause was not a valid comparison was first raised by executing the
describe command at the admin console for each of two different listeners,
both of which included the following:

UDPinfo: no
UDP sequence number: 2

and executing the describe command repeatedly a few times yielded the same UDP
sequence number.

okay, looking at the cvs comments right now i see that udpseqnr "is
increased
when a new title is set"

and from exploring a bit further just now, i see that with my change the UDP
sequence number was increasing within a song, and when i reverted to the
original code, it indeed increases between songs.  so i guess i just wasn't
patient enough the first time.  i'm still confused about use_udp, however.
> > it appears that this information should be periodically inserted into
the data
> > stream.  the behavior that i was seeing was that the information was
appearing
> > a maximum of one time and sometimes zero times.
> 
> Are you sure? It should change whenever the stream source does an
> "updinfo" command. Otherwise the information hasn't changed
and there
> is no point in wasting bandwidth resending it.
...
> > in my local copy, this is the only instance that i changed, and it
indeed
> > causes the metadata to appear periodically within the stream.
> 
> You've just forced clients to receive updates every metaint bytes
> instead of when the metadata changes. Take a look at what modifies
> udpseqnr.
part of the confusion may be that i'm not actually sure what the right
behavior is supposed to be, and i'm guessing based on my observations.  (i
don't suppose any of this is documented anywhere?)

yes, my change would cause the server to send the data periodically, and not
just once.  but that's what i thought it was supposed to do.

the reasons that i thought this was the intended behavior were as follows:  i
started looking into this with icecast 1.3.7, which had the following at the 
end of write_chunk_with_metadata:

        if (clicon->food.client->use_icy_metadata &&
info.use_meta_data && (client->cid % (info.metainterval / 4096) ==
0))
                write_chunk_with_metadata (source, clicon);
        else
                write_chunk (source, clicon);

i see that as of now (icecast 1.3.10 -- it looks from browsing the cvs
repository that it was version 1.22 of source.c that contained the change),
this now reads:

        if (clicon->food.client->use_icy_metadata &&
info.use_meta_data)
          write_chunk_with_metadata (source, clicon);
        else {
          write_chunk (source, clicon);

what i didn't get is why, in the 1.3.10 source, does add_chunk repeatedly
add
metadata to a chunk, then source_write_to_client calls
write_chunk_with_metadata which calls write_data_with_metadata, yet,
write_data_with_metadata has two paths, one of which writes the metadata and
one does not?  looking at the cvs comment for source.c 1.22 makes it a little
clearer that maybe that's just the way it's supposed to be, although
i'm still
a little confused.

if the metadata is not written periodically, what does the icy-metaint HTTP
response
header (which appears to be sent by both icecast and shoutcast if the client
sends an HTTP request header of 'Icy-MetaData:1') signify?

and if the metadata is only written once, why does add_chunk add it
repeatedly?  is the gist that add_chunk repeatedly puts it into the stream for
a given source, but write_chunk_with_metadata and write_data_with_metadata
only write it once per client?
> Metadata works fine for me without this change. What are you
> testing with?
icecast 1.3.10 server running on Red Hat Linux 6.1

mostly tested with Winamp 2.7 client running on Windows 2000, some testing as
well with xmms 1.0.1 on RHL 6.1, although i can't remember whether or not i
saw this specific behavior with xmms.

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 had assumed
that the title streaming would appear periodically in the stream, and i
started exploring further when tcpdump showed that it only appeared once, at
most.  and sometimes it didn't appear at all.  so if simply my assumption
about the multiple insertions was wrong, then the bug that i should look at
further is can i recreate the situation where it doesn't appear at all,
using
the original code.  i just reverted back to the original code and after a few
minutes of trying can't recreate the original bug, with either winamp or
xmms.
i'll report back if i do.  although it's possible that my original
observations were with 1.3.7.  i'm not entirely positive anymore.

if anyone can provide any further details about how the title streaming is
supposed to work [how is the client supposed to recognize the title as such?],
that would be great.  and what does shoutcast do?  [i had thought that it
periodically inserted id3 tags into the stream, but now i'm not so sure] and
why doesn't icecast just do whatever shoutcast does?

orry that this message got so long and rambling.  just trying to be
complete.

- rich

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

now add_chunk keeps adding metadata of the form StreamTitle=''

if you connect with a client, you don't get the title of the song

this fixes itself when ices moves on to the next song.

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.

- rich

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