similar to: Icecast install under Windows

Oh dear. Okay, can anyone suggest how to install Icecast under Windows as a service, and to be able to bring up some kind of console to start/stop it? I can launch Icecast using the installed .bat file, but it's clunky. -- that Jack Elliott 541 848 7021 Producer Wednesday Point, Host, The Sunday Classics KPOV 88.9, High Desert Radio Audio geek On 05/14/2015 09:21 AM, Ross Levis wrote:

Hi Marvin, I followed the wiki instructions and they went w/o any issues until C:\Users\username> nssm start Icecast Can't open service! OpenService(): Access is denied! Probably a good idea to mention that the command window needs to be Run as administrator. Then it works. Many thanks! -- Jack Elliott On 5/14/2015 10:07 AM, Marvin Scholz wrote: > On 14 May 2015, at 18:36, Jack

Ok. I installed icecast win_32 2.4.1 with no problem. The problems arrive when I try changing things... Why are the folders for icecast write protected? I made changes to the icecast.xml file & tried saving it, but got errors saying the file is read only! Then, I scanned the sub-folders in the download folder & found another icecast.xml file! I couldn't make changes that either!

Thanks, Albert, for the help on the IP address! I'm not sure what you mean about the Windows server. I'm running Windows 8.1 on my PC that runs the radio station... I figured out that the icecast.xml file in the sub-folder is the one that the icecast GUI uses for configuration. ________________________________________ From: icecast-bounces at xiph.org <icecast-bounces at

Yes, I think you might be on to something there. I'm tempted to switch to Linux for the streaming part of this setup... I have 2 Windows machines that I use now, 1 for the radio automation & the other for streaming & editing audio files. What Linux OS do you recommend? Ubuntu? What radio automation software do you recommend? I had Icecast working last year but when we upgraded

As described here in ffmpeg's documentation: http://ffmpeg.org/ffmpeg-all.html#Icecast -- That Jack Elliott (541) 848 7021 KPOV 88.9 FM High Desert Community radio Host, The Sunday Classics

I see. I'm not sure how I keep missing things in the Icecast docs. I'll give that location a try. Thanks On 6/3/15, Jack Elliott 541 848 7021 <thatjackelliott at kpov.org> wrote: > That one stumbled me, too. I'm on a Windows machine so my webroot is in > a different location. But according to > http://icecast.org/docs/icecast-2.4.1/config-file.html, the path to >

Marvin, Ah, thank you for clarifying where "webroot" is. The application here will be a non-public stream with one listener client. Icecast is hosted on a computer at our radio station. It will receive a stream from a stream client at a remote live music event. There will be one listener: a media player running on another computer on the network at the station which will send the

Hmm. Even with the file in the right place, Icecast still doesn't use it when my stream is offline. I can access the file using it's URL, so I know Icecast has access to it. This is what I have in my configuration file. <mount> <mount-name>/stream.mp3</mount-name> <fallback-mount>/StreamWarning.mp3</fallback-mount>

Hi, I see that I can use the "Kill Source" button on the Icecast admin web page to kill our fallback.mp3 file. Now that I have killed the fallback file, I don't see a way to re-start it. Do I need to stop / start the icecast service? -- That Jack Elliott (541) 848 7021 KPOV 88.9 FM High Desert Community radio Producer, The Wednesday Point Host, The Sunday Classics

Thanks, Brad -- I first turned to VLC but my stream-client device is a Raspberry Pi 3, and there doesn't seem to be a build for the device. That said, I just stumbled across mpg123, a command-line mp3/stream player that has audio buffer and timeout setting which so far looks quite robust. For Icecast2 content, when Icecast kicks a client off for being "too far behind" -- what

Ha! Terms even a broadcaster can understand! Many many thanks. If BUTT is considered to be as good a transporter as Icecast, then I will stick with what I'm doing, if for no other reason than, "Master is the source server (where the source comes from) and Slave is the relay. THe connection is initiated by the slave to the master." Slave may not know where the Master is. Master

It's behaving as it is meant to: if a listen client gets too far behind, Icecast2 server is kicking them off. error.log says, "INFO source/source.c Client 120 (xxx.xxx.xxx.xxx) has fallen too far behind, removing" I don't see a setting in icecast.xml that sets the value for "too far behind". I'm guessing it's related to <queue-size>. I wish Icecast

I'm just wondering if ffmpeg is a reliable Icecast source-client -- a "pusher" to send a stream to an Icecast server and runs 24/7/365 dependably. -- That Jack Elliott (541) 848 7021 KPOV 88.9 FM High Desert Community radio Host, The Sunday Classics On 8/27/2019 10:58 AM, Alejandro wrote: > When you say as Source Client, means like listener? > > i'm using for push

Hi Marvin, thank you. Okay, then to be clear, "webroot" for the purposes of running Icecast under Windows would be the same folder where icecast.xml is normally found, i.e., C:\Program Files\icecast And, if I read you correctly, suppose my normal mount coming from my source client is called /example (it is an mp3 stream so I don't specify the extension). If I place a file

Hi Philipp, Thank you. I find in the Icecast docs the following: "_A fallback mount can also state a file that is located in webroot._ This is useful for playing a pre-recorded file in the case of a stream going down. It will repeat until either the listener disconnects or a stream comes back available and takes the listeners back. As per usual, the file format should match the stream

/I made an error, I swapped two diagrams, it should be this:/ Here's how I've been doing it: BUTT ===> WAN ===> Icecast server I thought I might try this instead: BUTT --> localhost Icecast server ===> WAN ===> Icecast server -- That Jack Elliott (541) 848 7021 KPOV 88.9 FM High Desert Community radio Producer, The Wednesday Point Host, The Sunday Classics On

"Live streams are not live, they can be up to 15 to 20 sec off original encoding." Something you become aware of very quickly when you're announcing into a mic and have to wait to hear your words! We do a bit of pre-show calibration with folks at the station to determine how long the delay ("latency" in digital-speak) is at the start of the remote broadcast, and start

Right, BUTT can be set to push to studio, and studio's IP is fixed. It doesn't appear that Icecast Master can push to a Slave at studio, Slave at studio has to pull from Master, and Master's IP address is not fixed. So for our remotes, BUTT is the better choice for that, and all the other reasons you mention. Plus, when you are recording eight bands in a 12-hour broadcast day,

Hey, The relay easiest to configured in a pull configuration. Where the setting are setup on the remote server. Since the client is on WiFi, you will have lots of issues streaming due to the ever changing wifi environment. My suggestion is source the stream at the lowest settings for encoding you can live with, This will keep the bandwidth down and less likely burp on you. We do have