similar to: Any buffering on server?

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

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

On Friday 20 February 2004 00:09, Renaud Waldura shaped the electrons to shout: > 1- this is such a stoopid question I should be ashamed of myself -- > RTFM > > 2- this is a well-known issue that everybody's aware of, it doesn't > need further discussion thank you, as it is actively being worked on > > 3- it is meant to be that way and will not change. No, if you

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

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

I must use Windows for Streaming. and the interface must be an port or something else, because the software interface runs on a dedicated server. ----- Original Message ----- From: "Ricardo Galli" <gallir@uib.es> To: <icecast-dev@xiph.org> Sent: Wednesday, February 25, 2004 10:10 AM Subject: Re: [icecast-dev] I need a Freelance Coder... <p>> On Wednesday 25 February

On Friday 20 February 2004 12:10, Ricardo Galli wrote: > > wants to send such a patch, we're happy to integrate them. I don't > > remember the DoS bug - that might be a real problem. It could be that a > > It started out with this: > > http://www.xiph.org/archives/icecast-dev/0366.html > > and I found the problem and sent the patch: > >

This small example will make icecast unusable after few seconds. The problem resides on EPIPE received when trying to send the first (58) bytes of the vorbis predata. Change the URL for your own, and try it in a LAN. I have no idea 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

Is there anybody who can help my for implement a feature in icecast 2? I want to update ogg vorbis meta data album/title/genre/artist via an webbased interface. like metadata.xml for mp3 files. If there`s anybody, contact my benny@name-pool.net i would pay for this feature. thanks --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To

On Monday 10 February 2003 13:25, Michael Smith shaped the electrons to shout: > If it takes this long, then there's something else wrong. It should be > well under a tenth of a second (and probably closer to 1/100). No, nothing wrong, at least darkice is doing very badly. With darkice as encoder at about 30 kbps, there are about 3 buffers per second, which mean that in the worst

On 19/02/02 23:09, Likai Liu shaped the electrons to say: > Ricardo Galli wrote: > >By assigning a timestamp to each packet read from the source socket. I > > think the only sane way to do it. > > great idea. with this implementation, actually you can set a smaller > buffer size, but wait a longer time for recovery. once congestion is > clear, previous "missed"

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Huh, why not just use ices with a perl song choser module ? This eliminates the need to develop the libshout based streamer (use ices instead) and give ices the title from your module, ices will take care of the rest. Or I am wrong ? :) On Wed, 25 Feb 2004, Renaud Waldura wrote: > For what's it's worth, I do something similar to this

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

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*

On Friday 20 February 2004 01:50, Michael Smith shaped the electrons to shout: > > |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

Hi Mike Find enclosed the patch with the fastart implementation for vorbis (for the moment). Now is based on size in bytes and the buffers are sent all together with pre_data. Hope you like it. At least is the smallest one: :-) -rw-r--r-- 1 gallir gallir 5486 2003-01-21 01:29 update3c.diff -rw-r--r-- 1 gallir gallir 10014 2003-01-19 20:14 update3b.diff -rw-r--r--

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 send() any byte to check if the TCP buffers are full due to network congestion. See below the warning messages of "normal" (at least in

I am trying to determine the optimal filesystem for accessing large numbers of files (25,000+) in a single directory. I have read that ext3fs uses a sequential search algorithm and wanted to verify that this was still indeed the case since this article was published a year ago. http://bulmalug.net/body.phtml?nIdNoticia=1154 <http://bulmalug.net/body.phtml?nIdNoticia=1154&nIdPage=7>

Hi Mike, find the patch for faststart that takes in account different logical streams. I tried with ices' playlist, it works just fine [*]. I could be still further optimised, but it will make the code less clear (for example, I could check for has_paredata before checking for serailno, which saves a couple of calls and also will avoid any change in format_mp3.[ch]). <p>[*]

In format_mp3.c tatic int format_mp3_write_buf_to_client(format_plugin_t *self, client_t *client, unsigned char *buf, int len) { int ret; if(((mp3_state *)self->_state)->metadata) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is always true because previously it did state->metadata = strdup("") in format_mp3_get_plugin(). It causes annoying artifacts in xmms