search for: mcrg

...on the reasons of these errors, altough I suspect it's related to the fact that the headers are sent in blocking state and then we change to non-blocking. I will try to put all headers in a refbuf and append it to the client queue. for i in `seq 100` do echo $i timelimit -s 3 wget -q http://mcrg.uib.es:8000/live.ogg & timelimit -s 3 wget -q http://mcrg.uib.es:8000/live.ogg & timelimit -s 3 wget -q http://mcrg.uib.es:8000/live.ogg done <p>(timelimit is a small program in C to limit the execution of the command to 3 wallclock seconds). /****** timelimit.c *******/ #includ...

...t; > 3- it is meant to be that way and will not change. No, if you search old archives (almost two years ago, http://breu.bulma.net/?l2480) you will see I've sent patches for server buffering (fast start) and other things that were never included. You can check the difference with http://mcrg.uib.es:8000/live.ogg which run my code realiable for more than a year now. The server also had a remote DoS bug, I sent the patch also and it was not included, I did not receive any answer neither, so I just stopped. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/~gallir/ Recu...

Hi, Thanks Mike. So is there any buffering done on the server, or is it all on the client? i.e. when a server first connects, does it get a "burst" of packets until it catches up to the current time? Thanks, Martin --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to

On Monday 10 February 2003 04:29, Michael Smith shaped the electrons to shout: > Other than the headers, there is no deliberate burst at initial connect > (but there will be an option for this soon). You can try it (48 KB of startup buffers) at: http://mcrg.uib.es:8000/live.ogg and http://mcrg.uib.es:8000/high.ogg The only think I'm still not very convinced is that clients has to wait for at least 1 "source iteration" (and 2 in the worst case) in order to beging to receive any data at all. This is due to the algorith: while (source)...

...size, but wait a longer time for recovery. once congestion is > clear, previous "missed" packets are thrown away, and new packets > continue to flow. that introduces skips but overall latency control is > better. i like your idea. I am trying it now, you can do it also at http://mcrg.uib.es:8000/live.ogg <p>It's configured with a prebuffering of 5 seconds, and a maxlag of 10 seconds. If a refbuf for a given client exceeds 10 seconds, and it's not a partial packets, it is silently discarded and removed. The "core" is shown below: if(abuf->timestamp...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry. The patch is hopely here. On Saturday 18 January 2003 03:38, Michael Smith shaped the electrons to shout: > > Hi, > > find a patch which is an update to a patch sent months ago. Before > > it was in net/sock.c, now I moved it to format.c, so net CVS module > > is not affected. It polls the socket before trying to

> |No, if you search old archives (almost two years ago, > |http://breu.bulma.net/?l2480) you will see I've sent patches for server > |buffering (fast start) and other things that were never included. > | > |You can check the difference with http://mcrg.uib.es:8000/live.ogg which > |run my code realiable for more than a year now. > | > |The server also had a remote DoS bug, I sent the patch also and it > > was not > > |included, I did not receive any answer neither, so I just stopped. > > It's not a good news. I thin...

...t;3- it is meant to be that way and will not change. | | |No, if you search old archives (almost two years ago, |http://breu.bulma.net/?l2480) you will see I've sent patches for server |buffering (fast start) and other things that were never included. | |You can check the difference with http://mcrg.uib.es:8000/live.ogg which |run my code realiable for more than a year now. | |The server also had a remote DoS bug, I sent the patch also and it was not |included, I did not receive any answer neither, so I just stopped. | It's not a good news. I think that devs should be expected to merge int...

...gt; |No, if you search old archives (almost two years ago, > > |http://breu.bulma.net/?l2480) you will see I've sent patches for > > | server buffering (fast start) and other things that were never > > | included. > > | > > |You can check the difference with http://mcrg.uib.es:8000/live.ogg > > | which run my code realiable for more than a year now. > > | > > |The server also had a remote DoS bug, I sent the patch also and it > > > > was not > > > > |included, I did not receive any answer neither, so I just stopped. > &...

On 19/02/02 18:09, Likai Liu shaped the electrons to say: > >It's partially done in the patch I've sent you, completelly done in my > >current version... I can send you the second patch, you will save some > > work. > > how is the calculation being done? do you extract the bitrate from the > stream data, or do you use a different method? I'd advocate *that*

Hi all, I am ricardo galli, I've juscribed just a couple of days ago. I wanted to stay as a lurker for a longer period, but this list has almost no traffic, so I wake up due to the silence. The point is, is this list related to icecast2 development? I made some changes to the server and sent a patch to Jack Moffitt, but I'm not sure he's still mainaining the server. If he

There appears no source buffering in Icecast 2.0. Please correct me if I'm wrong -- my C skills are a bit rusty -- it looks like apart from a tiny 4K buffer, there is no buffering done when relaying a source. Is this an explicit design decision? The Internet being what it is, unreliable and all, it seems harsh to drop a source that's even slightly lagging, when a bit of buffering could

.... Moved queue_lenght verification to the send_client_queue(). It doesn't make sense to do it if there is no pending buffers. 7. Added TCP_NODELAY to a nonblocking socket. It is said that it's improve performance in Linux. TODO: check Win32 compatibility. You can try my version in http://mcrg.uib.es:8000/live.ogg (if the server is down, please wait few seconds and try again, I am restarting it frequently for my tests). Conclusions: _very_ stable connection, it recovers from network congestion very nicely. Don't hesitate to ask me for changes or improvements to my patch. <p&...

.... Moved queue_lenght verification to the send_client_queue(). It doesn't make sense to do it if there is no pending buffers. 7. Added TCP_NODELAY to a nonblocking socket. It is said that it's improve performance in Linux. TODO: check Win32 compatibility. You can try my version in http://mcrg.uib.es:8000/live.ogg (if the server is down, please wait few seconds and try again, I am restarting it frequently for my tests). Conclusions: _very_ stable connection, it recovers from network congestion very nicely. Don't hesitate to ask me for changes or improvements to my patch. <p&...