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

[Richard Fromm]

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