> No, what I meant by instances was multiple non-forked instances of the > executable in the process table, ie icecast run multiple times with different > port options. I see from your answer below that this is no longer possible.If you run multiple copies of icecast, they will be completely separate, and work as two separate entities. I have run many instances of icecast on the same box all on different ports, with little problems. For each single instance, you can ask it to listen on multiple ports, which all act the same. But two instances ports are separate. And the icecast instances won't even know about each other.> jack> You likely are using the wrong option to iceplay (god knows why you are > jack> using that really outdated and inadequate tool). > > Because the version I'm using is neither outdated nor inadequate. It's been > improved by other people and it works great. The version I'm using has mysql > as a back end for keeping album and playlist information (and everything is > handled via a web interface for creating, editing, and choosing playlists, > requesting songs, etc, but that's not part of iceplay, that's just the stuff > that wraps around it. Very similar to dj lizard).I would suggest replacing the send loop in iceplay with the Shout perl module, which uses C code for timing. Perl is just not good enough to do accurate timing, and you'll get artifacts and skips and disconnects more often than with something that's using the reliable code. In any case, if it works for you great :) At a certain point, I could no longer get reliable streams out of it. My testing showed perl to be just a bit to course grained to do what it needed to do.> I'll see what I can do with that mount points instead of using different > ports. Thanks for the info.The different ports will work across multiple instances. But they are equivalent on a single instance. For example: icecast isntance one, running on ports 8000, 8001, 8002 icecast instance two, running on ports 9000, 9001, 9002 8000,8001,8002 will all act identically with no difference. 9000,9001,9002 will all act identically with no difference 8000,1,2 and 9000,1,2 will not be anything alike. They will not share sources or anything else, unless you've explicitly done this. (eg, sending the same stream to both servers). Running two icecast's on one box is functionally the same as two icecasts on two different boxes. Hopefully this clears things up a bit. jack. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> Is it better to run multiple icecasts on different ports or several mount > points under one icecast from a performance standpoint?IMO (I haven't tested this theory) it is by far less resource intensive to use mountpoints. - mountpoints are a thread, not a whole process. it shares memory and other context with the others. The real problem comes with scaling. Due to some architecture flaws (these are addressed in 2.0) icecast can only reliable handle about 50-75 mountpoints on one server. Most people won't even get near this, but when we were broadcasting close to 500 stations, it was an issue. Above about 50 mountpoints, I find it's best to break into multiple servers, with 50 mountpoints on each. With icecast 2.0, I'm hoping that this problem goes away. The _only_ reason to use multiple instances over multiple ports is geenrally if you feel you must use multiple copies of teh winamp dsp plugin from the same machine. Or, if you must list more than one station in yp.shoutcast.com (since it only supports one per port, and has no concept of mountpoints). Personally, I find that limitation unbearable. It's like having a web server than can only serve one file. Or a search engine that only lets you list one file. In any case, if you have a choice, go with mountpoints. jack. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Hi Folks: I have had need to write a streamer and scripts to stream audio content on demand. Basically a person browses through a directory tree and selects a file to listen to at which point a stream is created and pushed to the listener through the icecast server. My questions start with is there anyway in the server to set a variable to kill/terminate a source when it has no listener anymore? I have sifted through the manual.html fairly well and don't see anything which exactly relates to my need. I am aware of the feature to kill a relayed source when there are no more listeners. If this feature isn't available would it be worth me or someone else modifying icecast to provide the setting. Is there any other way people can think to accomplish the same result? I have been considering a script to grep through netstat and then kill the streamer if it's listening socket is no longer connected but this seems like a bit of a kludge. Secondly, I wish this to eventually work with vorbis and was wondering what mime type I should return for a .ogg stream? I have many other questions but I think I will start with these. If anyone else is interested in this suite when I am finished, I will happily make it available. Kirk -- Kirk Reiser The Computer Braille Facility e-mail: kirk@braille.uwo.ca University of Western Ontario phone: (519) 661-3061 --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Is it better to run multiple icecasts on different ports or several mount points under one icecast from a performance standpoint? Hunter> From: Jack Moffitt <jack@icecast.org> > Reply-To: icecast@xiph.org > Date: Fri, 1 Jun 2001 10:30:06 -0600 > To: icecast@xiph.org > Subject: Re: [icecast] different play lists on different ports? > > For example: > > icecast isntance one, running on ports 8000, 8001, 8002 > > icecast instance two, running on ports 9000, 9001, 9002 > > 8000,8001,8002 will all act identically with no difference. > > 9000,9001,9002 will all act identically with no difference > > 8000,1,2 and 9000,1,2 will not be anything alike. They will not share > sources or anything else, unless you've explicitly done this. (eg, > sending the same stream to both servers). > > Running two icecast's on one box is functionally the same as two > icecasts on two different boxes. > > Hopefully this clears things up a bit.--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Fri, Jun 01, 2001 at 10:30:06AM -0600, Jack Moffitt wrote:> I would suggest replacing the send loop in iceplay with the Shout perl > module, which uses C code for timing. Perl is just not good enough to do > accurate timing, and you'll get artifacts and skips and disconnects more > often than with something that's using the reliable code. In any case, > if it works for you great :) At a certain point, I could no longer get > reliable streams out of it. My testing showed perl to be just a bit to > course grained to do what it needed to do.in adding VBR support, I must've fixed the timing issues that send loop was having. instead of having a preset time-to-sleep based on a preset bandwidth, I have iceplay calculating the time-to-sleep based on the leftover time after building up a second's worth of VBR MP3 packets. arr is using my code, which I submitted a while ago, but after iceplay had been tossed out in favor of Shout. -jer -- jer@sidehack.gweep.net Programmer / Sysadmin / Gweep mpython@gnu.org -><- Author of Xtacy, an X11 Graphics Hack jer_johnson@real.life.edu http://www.gweep.net/~jer/index.html ICQ#: 19599864 AIM: DruelChaos MSN: Nope --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.