similar to: log analyzers

There seems to be some discrepancy between rpcclient's man page and "rpcclient --help" in regards to the servername. It seems that the proper usage of rpcclient is rpcclient [options] server this is the format that is specified in "rpcclient --help." rpcclient's man page, however specifies that the servername should come directly after rpcclient. I.E.

I'd love to take a look at this script, and, more than likely, I'm not the only one :) Please post an example. > Liveice definitely needs a keepalive script of some kind. It's tricky, > though - since it can lose connection to the server & stop streaming, but > continue to run. The only truly reliable keepalive I've used polls the > server to see if it says the

Matt -- I actually came up with a much more elegant script. On FreeBSD there is a command 'fstat' (I'm sure this could be modified to use 'lsof' or something of the like). First of all, while liveice and icecast are running properly, # fstat -m | grep liveice |wc -l for me yeilds 56 or 57. I let liveice die and checked again, and that number went significantly down.

i run the latest CVS versions of: icecast / liveice / lame without problem on freebsd-4.3. > I am very tempted to try and use icecast as the weapon of choice > to realize a live audio stream for the radio station I work for. > > Now, the last time I tried the FreeBSD port of Icecast, it > immediately consumed something like 95% CPU time, even without > any client connected. I

> > Ices will reload the playlist file if it changes on disk. So if the > > file changes every track, everything will be fine. Alternatively you > > could write your MP3 to a FIFO, which ices could pipe to your icecast > > server. > > that looks like an interesting alternative, tho i have no clue how to do > that, and particularly in the context of otto (which,

> If you want something broken and stupid, the original patch you posted > will probably work ok. Change 'while (1) {' to just '{'. > > Being young and naive, I am still surprised when people are willing to > work twice as hard to do things the wrong way, just because they heard > about that way first. > being old and lazy i'm willing to take the easy

> assuming otto can execute an arbitrary shell command whenever the > track plays (I assume it can call whatever mp3 decoder you want), you > can > a) have a script that does something like > echo $1 > /path/to/playlist.txt > Then ices will reload the playlist file (size: one entry) at the end > of the track. > > b) do > mkfifo ices.fifo > echo ices.fifo >

> I'd love to take a look at this script, and, more than likely, I'm not > the only one :) > > Please post an example. > > OK - This is a quick & dirty hack - I'm sure there are several more elegant solutions... But it works. NOTE: this is designed for a Shoutcast server. You'd need to change the check= lines to work with Icecast. Couldn't find an

running: latest CVS of icecast-1.3.11, liveice, and lame. i initially launch the server with the following shell script: #!/bin/sh /usr/local/bin/icecast -c /usr/local/etc/icecast/conf/icecast.conf -b /bin/sleep 5 /usr/local/bin/liveice -F /usr/local/etc/liveice/liveice.cfg >/dev/null 2>/dev/null & everything runs fine for a random period of time (sometimes hours, sometimes days) until

I've been through this on the list a while back. Unfortunately what you are asking is not possible, nor are the authors of ices interested in solving your problem :) I'd recommend ices-0.0.1.beta5.tar.gz (as recommended by otto's author) and seeing otto/misc/icecast/ices.readme. I use the recommended setup things run great. brian moseley wrote: > > hiya. i'm using ices

http://www.xiph.org/archives/icecast/1732.html Apply the same concept using the "lsof" command and you should be set. GHERdO wrote: > > Hi ppl! :) > > I'm streaming a LIVE radio station with icecast 1.3.11 and liveice. It > works, but I've a problem: > > >[04/Jan/2002:18:48:51] [9:Source Thread] Didn't receive data from source after 500000

I've been trying to figure out as to why sometimes connections are properly negotiated and sometimes not. For example, using mpg123 as a client, I point it at my server (live.wuga.org): Directory: http://live.wuga.org/ Playing MPEG stream from ... MPEG 1.0 layer I, 96 kbit/s, 44100 Hz stereo Illegal Audio-MPEG-Header 0x62dd8776 at offset 0xfffffffb. It has

hello alexander... you may or may not be acquainted with the program otto; it is a web-based jukebox solution. it has the ability to play both locally as well as to an icecast server via ices. however, as there is not a static playlist, ices needs to to exit after streaming an individual song. the author of otto had the following suggestion for stream.c per ices-0.0.1.beta5: --- i modified the

Since upgrading our openldap (v1.2.13) server to 4.8-STABLE from 4.7-STABLE, we've noticed that the slapd server increasingly eats up memory, before dieing and coredumping after about 15 minutes. I rebuilt the package (via ports), post-upgrade, to see if that fixed the problem and no dice. I've rebuilt libc_r and the pkg with debugging symbols, yielding the following: # gdb ./slapd.static

Hi, I'm running smbd 2.2.8. I'm a little green when it comes to file locking with samba. I have two users that access a single data file on a FreeBSD box. It's a moneydance data file and obviously it gets messed-up if two users are writing to it at the same time. Is there a way with samba to stop a second instance of the file from being opened, something like a "File In

On Wednesday, 01 August 2001 at 16:37, Robin P. Blanchard wrote: > > assuming otto can execute an arbitrary shell command whenever the > > track plays (I assume it can call whatever mp3 decoder you want), you > > can > > a) have a script that does something like > > echo $1 > /path/to/playlist.txt > > Then ices will reload the playlist file (size: one entry)

>I've often wondered whether it would be worth connecting a >very large serial EEPROM to a serial port interface, and >have it effectively appear as a solid state printer, (to >that you could cheaply log to an unmodifyable device). >Has anybody ever tried this? >John. Dot Matrix or an old printer would come in handy here with a (near-)infinite number of paper feed. :-) A

On Wednesday, 01 August 2001 at 15:12, Robin P. Blanchard wrote: > > > > Ices will reload the playlist file if it changes on disk. So if the > > > file changes every track, everything will be fine. Alternatively you > > > could write your MP3 to a FIFO, which ices could pipe to your icecast > > > server. > > > > that looks like an interesting

Hi ppl! :) I'm streaming a LIVE radio station with icecast 1.3.11 and liveice. It works, but I've a problem: >[04/Jan/2002:18:48:51] [9:Source Thread] Didn't receive data from source after 500000 microseconds, assuming it died... >[04/Jan/2002:18:48:51] [9:Source Thread] Lost connection to source on mount /radio, waiting 30 seconds for timeout What can I do? I have no idea

Hi, > icecast / liveice / lame > > without problem on freebsd-4.3. thanks a lot. How about OSS then, no troubles? What sound card do you use for A/D-changing? -- Radio HUNDERT,6 Medien GmbH Berlin - EDV - j.muenther@radio.hundert6.de --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a