similar to: Anyone using ffmpeg as a source-client?

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

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 >

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:

Windows 7, Icecast 2.4.1 Installer downloaded from http://downloads.xiph.org/releases/icecast/icecast_win32_2.4.1.exe Referring to http://en.flossmanuals.net/icecast/windows/ The installation process goes as described, but doesn't offer the "Create a desktop icon" option. Nor am I offered the option to "Install Icecast as a Windows service" as shown. I can't

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

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

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

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

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>

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

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

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

/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

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!

"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

readme.txt in archive and comments in ices.conf 14.09.16 14:12, Jack Elliott пишет: > > Any documentation for this? > > -- > That Jack Elliott > KPOV 88.9 FM High Desert Community radio > Producer, The Wednesday Point > Host, The Sunday Classics > On 09/13/2016 04:48 PM, Andrey Vasilkin wrote: >> IceS-ne 0.4.2 for OS/2, eComstation and Windows based on Centova

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

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

Fraunhofer Institute for Integrated Circuits has stopped providing licenses for MP3 technology, "[...] noting that more superior audio formats have rendered the MP3 obsolete. Speaking to National Public Radio (USA), the Fraunhofer Institute said AAC has since become the 'de facto standard for music download and videos on mobile phones.' "