similar to: PATCH3: icecast2 hangs on close

On 19/02/02 06:14, Jack Moffitt shaped the electrons to say: > > well, at 128kbps bitrate, it's only 6 seconds of data. 30 seconds would > > have been more reasonable, how does everybody think? it might have to be > > varied based on the bitrate of the stream. > > Good point. I will make this configurable in the end. 6 seconds is too > little. I'll see what I

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

On 19/02/02 03:06, Jack Moffitt shaped the electrons to say: > > 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. > > You're in the right place, and I still maintain the server. I don't > remember your patch right

On 24/02/02 05:02, Jack Moffitt shaped the electrons to say: > > - The server didn't check for the status of the client's socket before > > the unblocking send(). This caused a disconnection at a minimun network > > congestion, causing a broken pipe error (Linux 2.4 behaviour?) in the > > network. I've just added a poll in sock.c.> > Can you send me this

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

I send a patch again the last CVS version. The changes are: - Configurable prebuffer, in seconds. - prebuffering parameter in configurable in <limits>...<prebuffer>seconds</prebuffer>... - Created a new function (send_client_queue) to send the client->queue. Better modularisation. - Moved queue_lenght verification to send_client_queue(). - instead of disconnecting when

> most probably this patch won't be applied either, nevertheless, I inform the > problems and my own modifications.... Why wouldn't we apply this patch? This one is mostly obvious, and we thank you for catching it. Some of your other patches change quite big things. If I accepted every patch that was sent to me without some research and effort, icecast would fall into ruin very

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"

Jack Moffitt wrote: >As for the other parts, I do not understand why we shouldn't kick >clients who fall 25 packets behind. That is more than 100k usually, and >surely you don't think we should buffer them forever. > well, at 128kbps bitrate, it's only 6 seconds of data. 30 seconds would have been more reasonable, how does everybody think? it might have to be varied

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mike, I think you dealing with the development. Almost a year ago I've sent few patches to Jack, several of them are already applied to the current version. I'm back again, and tested the last version. I noticed it isn't as resilient to network congestion as my last patched version (just disconnect the ethernet cable of

I mount another Linux machine with: smbmount tillie/all /mnt/tillie -o uid=0 Trying to copy a root owned to file after either su or su - fails with: cp: cannot create regular file `/mnt/tillie/usr/local/bin/smbmt': Permission denied Since I have root priviledges why does this happen? The file perms are: -rwxr--r-- 1 root root 4.6K 2006-05-02 16:58 smbmt I get the following message on

On 24/02/02 08:17, Ricardo Galli shaped the electrons to say: > > > - Added TCP_NODELAY to a nonblocking socket. It is said that it's > > > improve performance in Linux. TODO: check Win32 compatibility. > > > > What's it supposed to do in general? I've had varying success with the > > advanced socket options. > > Turn the Nagle algorithm off,

Jack Moffitt <jack@xiph.org> writes: > I assume the public flag is not set for that source. I don't see it in > there. Ah ha! I think I found the problem. Remember my setup is: xmms -> darkice 0.7 -> relay icecast server -> main icecast server | +->to other networks Darkice has: public = yes So I check

On Sun, Feb 24, 2002 at 09:04:03AM +0100, Ricardo Galli wrote: > Sorry, didn't explain well. > > Nagle's algorithm (rfc896) buffers user data until there is no pending acks > or it can send a full segment (rfc1122). > > icecast doesn't need it at all, because it already sends large buffers and > the time to send the next buffers is relatively very long. IMO

I have a Slackware Linux box called Tillie with three shares. All at /, user at /home/user and public at /public which is "guest ok" for access without a password. The problem is that Tillie shows up in Windows Network Neighborhood as a single icon. To open that icon and see the three shares Windows demands a password, thus making it impossible to access. Is there any way to get

On 22/03/02 22:24, Jack Moffitt shaped the electrons to say: > > It the first problem I found when I started to use the server and the > > reason I began to modify it. The patch is sock.diff > > I still don't understand the problem, nor have I reproduced it. > > We shouldn't need to check the status of the socket before we call > send(). If there were any send

I have watched the discussions about the size of the R user base with much interest. One more source of data that might help is the voluntary data capture in Debian. If you are a Debian user, you should volunteer information. It's very easy: as root, say: # apt-get install popularity-contest The results are found at: http://popcon.debian.org/main/math/by_inst This shows that of the

Dear developers, I patched ogg123 so that it can use esd (only local socket currently). In order to compile you need to copy esd.h from the esound-devel to the vorbis-tools directory. Usage: ogg123 -e -d something file.ogg the "something" is not important I don't intend to maintain this patch, but perhaps somebody could make it more nicer and incorporate it in the

Hi all, I need some help with the following problem: I need to migrate a bunch of user accounts to another domain on a Windows 2003 server (eventually to 2008R2, but that step seemed to big to do in one go). To keep all access rights etc. correct, I need to get the SID history set correctly as well. From what I've researched so far, I'm aware of