Richard Fromm
2004-Aug-06 14:57 UTC
[icecast-dev] bug report w.r.t. streaming of metadata in icecast
i've been trying to get title streaming of metadata to work with icecast 1.3.10. i've found what i believe to be a bug -- is this the right place to file a bug report? 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. 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) { if the client is connecting with tcp, then i assume that the comparision of udp sequence numbers is meaningless. therefore, does any use of udpseqnr within a client_t structure need to be conditioned with use_udp ? in my local copy, this is the only instance that i changed, and it indeed causes the metadata to appear periodically within the stream. my guess, however, is that all instances of client_t.udpseqnr need to be conditioned with client_t.use_udp - rich fromm --- >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.
Richard Fromm
2004-Aug-06 14:57 UTC
[icecast-dev] bug report w.r.t. streaming of metadata in icecast
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.
Brendan Cully
2004-Aug-06 14:57 UTC
[icecast-dev] bug report w.r.t. streaming of metadata in icecast
On Tuesday, 07 August 2001 at 12:56, Richard Fromm wrote:> i've been trying to get title streaming of metadata to work with icecast > 1.3.10. i've found what i believe to be a bug -- is this the right place to > file a bug report?I think so.> 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.> 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.> if the client is connecting with tcp, then i assume that the comparision of > udp sequence numbers is meaningless. therefore, does any use of udpseqnr > within a client_t structure need to be conditioned with use_udp ? > > 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. Metadata works fine for me without this change. What are you testing with? -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.