search for: tilly

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

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

This is a problem I get with various versions of Samba, up to and including 2.0.7. (The version shipped with Debian.) I have an NT machine (4.0, service-pack 3 using NTFS) exporting a filesystem to Linux through smbmount. Specific directories are not browsable. By that I mean that "ls *" comes up blank, however if you know the filename, "ls foo.txt" will still find the

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

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 again, most probably this patch won't be applied either, nevertheless, I inform the problems and my own modifications.... Included in the patch (just touches sock.c and sock.h): - Due to the semantics of the close() function, the server hangs on close() if a client just dies (the machine just "dissapear" from the network) and there is still data to send in the TCP

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

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

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

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

Is there a file I can place in the netlogin directory (or anywhere else for that matter) that will represnet a logon script? I want to have my workstations auto-mount particular shares on the samba server, without the user having to make the mount. This way when I add new users, the shares are automatically present. If there is a script I can place somwehre, please tell me what it's name is

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

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

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

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

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

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