search for: udpseqnr

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

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

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

Hi Karl, Thanks for your help, About the "Connection:" header, you are right, it's: "Connection: close" and NOT "Connection: keep-alive". The protocol when the SERVER sends the data is http 1.0. It's http 1.1 when the browser requests the data. I don't understand the "Content-Length: 54000000" header either. Also I noticed the flash player on

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

...t;x-audiocast-streamurl") != NULL) + { + if (lasturl && g_strcmp (valptr, lasturl)) + { + c_message (stderr, "Song URL: %s\n", valptr); + g_free (lasturl); + lasturl = g_strdup (valptr); + } + } + #endif + else if (strstr(lines[i], "x-audiocast-udpseqnr:") != NULL) + { + gchar obuf[60]; + sprintf(obuf, "x-audiocast-ack: %ld \r\n", atol(valptr)); + if (sendto(sock, obuf, strlen(obuf), 0, (struct sockaddr *) &from, fromlen) < 0) + { + g_log(NULL, G_LOG_LEVEL_WARNING, + "udp_check_for_data(): Una...