Brendan Cully
2004-Aug-06 14:57 UTC
[icecast-dev] 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.
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.
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, 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.