similar to: PATCH: increase network congestion resilience

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

On Friday 17 January 2003 20:17, Karl Heyes shaped the electrons to say: > I would suggest a slightly different approach. > > Instead of increasing the syscall overhead for all sockets, trapping > for uncommon cases. Try the sock_write_bytes and if that is > continuously having to queue (ie not all data can be sent) then display > the warning, maybe make it a run-time option

On Saturday 18 January 2003 03:37, Michael Smith shaped the electrons to shout: > We can't just drop packets, the transmission model assumed by the > format handlers (and required by at least one of them) will not permit It's not vorbis. Does it? > us to drop any data. It'd be possible, in theory at least, to tag > buffers with a flag to say that they can be dropped, but

Hi, I've been doing some experiments today with ices, icecast-2.0.1 server and using ogg123 to play the stream on a client device... Twice, the client appears to "lock" at around the same point - once at 189:45:56 and the second time at 187:45:40. The server log states: [2004-05-30 17:28:50] DBUG format/format_generic_write_buf_to_client Client had recoverable error -1

I'm using the latest CVS source under Linux using a playlist of ogg files. When I use a client to connect on the same machine, there is not any disconnect (xmms and zinf). When using a client on a Windows machine, I get mixed results. Zinf on windows will play thru the current song but then stops when the song is finished and does not play the next song being streamed (see log below).

On Saturday 18 January 2003 16:04, Michael Smith shaped the electrons to shout: > On Sunday 19 January 2003 01:59, Ricardo Galli wrote: > > On Saturday 18 January 2003 03:37, Michael Smith shaped the electrons > > to > > > > shout: > > > We can't just drop packets, the transmission model assumed by the > > > format handlers (and required by at

Hi, I can get ices2/icecast2 to broadcast ogg files in a playlist to FOOBAR in MS-Windows (and various apps in Linux). When I try to connect in WinAmp in MS-Windows, I get in error.log: [2004-02-04 21:38:39] DBUG source/source_main Client added [2004-02-04 21:38:41] DBUG format/format_generic_write_buf_to_client Client had recoverable error -1 [2004-02-04 21:38:42] DBUG

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

Hi I'm running Icecast2 with the IceS streamer which was installed from the ports on FreeBSD. Everything seems to be fine with my configuration as it starts up fine but as soon as I connect using a client like Media Player or WinAmp I see the following in the error.log [2003-10-27 21:00:27] DBUG format/format_generic_write_buf_to_client Client had recoverable error -1 [2003-10-27 21:00:27]

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

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 enclosed the patch to move the logic of clients' queue data to a function. Later I'll provide you the patch to use a [configurable] queue size in bytes instead of number of refbufs (see the footnote). Regards, <p>[*] I was doing some testing with MP3, aside it has some nasty bugs [**], lame encoder sends very small packages, about 350 bytes in size,

Hello, after the reply of Jerome Alet, I forward our questions to you. I hope it is now the right place to put it. Could you please send your answers, questions, comments to interopcast-general@nongnu.org so everyone in the group can get a copy of it. Thank you. ----- Original Message ----- From: "Jerome Alet" <alet@librelogiciel.com> To: <interopcast-general@nongnu.org>

On Sunday 19 January 2003 03:35, Michael Smith shaped the electrons to shout: > There's a bad interaction here between the predata and this faststart. > Suppose we have two logical streams (A and B), and the stream has just > recently got to logical stream B. Now, this means the fast start queue > contains the end of stream A, then the stream B headers, then the start > of

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

I have just setup icecast on my RedHat 9 server and it's working fine except that every 2 minutes or so I get an error in icecast error log giving about 20 lines of : DBUG format/format_generic_write_buf_to_client Client had recoverable error -1 And then DBUG source/source_main Client has fallen too far behind, removing It then restarts streaming to the client The result is that the music

Hi, find enclosed a patch to implement faststart (or prebuffering). Basically, it stores a number of "refbuf"s, configurable by seconds. When a new client connects, it adds the prebuffers to que clients' queue so they are delivered as fast as permitted by the connection. As result, the players prebuffers are filled up faster giving a better "response". I tried

Hi there, I just joined the list and have a question on one of the earlier posts: On Oct 28 2003, Ricardo wrote that his server diconnected his clients. I have the exact same problem - and a bit of testing/analysis. <p>I am running an Icecast server and IceS on the same linux box. IceS is encoding a live stream from my sound card. After a while of listening (approx 2 mins) from another

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>[*]