similar to: Question about Icecast2 when not streaming

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>

I magically manage to overlook more in those docs than I see. I blame it on the font. Or the colors. Can't be me. Nope. -- that Jack Elliott 541 848 7021 Producer Wednesday Point, Host, The Sunday Classics KPOV 88.9, High Desert Radio Audio geek On 06/03/2015 01:41 PM, Kyle Blizzard wrote: > I see. I'm not sure how I keep missing things in the Icecast docs. > I'll give that

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 >

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 webroot is in your icecast.xml file, i.e., webroot: This path specifies the base directory used for all static file requests. This directory can contain all standard file types (including mp3s and

On 1 Jun 2015, at 17:39, Jack Elliott 541 848 7021 wrote: > 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

"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

Hey, Something about streaming. Live streams are not live, they can be up to 15 to 20 sec off original encoding. This is to to overhead on both the server and client for encoding/decoding the stream, Any trans coding, and and buffering that has to be done on a "slow" connection. Unless the client decoder has some way to sync the stream, this delay will grow tell icecast

Hey, Yes, we been just using a simple source client connecting directly to our icecast server for years. These being a simple free solution. Also works with other free and paid for products too. Your milage will varry with each program, and what features it will offers. For dynamic IPs you can use a service like noip.com. There are a few of them to choose from. IT allow you to give your

It does not matter what IP BUTT has, it sends to the fixed IP at the studio on port [ 8000 ] with a mount like /liveBroadcast.mp3 On 21/04/17 11:05, Jack Elliott wrote: > > 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,

On 1 Jun 2015, at 16:31, Jack Elliott 541 848 7021 wrote: > 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 The webroot is where the web files are, so it should be `web` on Windows and contain files like

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,

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

ok let see if I can translate it to broadcaster terms for ya :) A icecast server can be set up to accept direct source connection. ie dark ice( which i do agree runs better on the machine where icecast server is. ) I do use it to trans-code the mount to different encoding. THe icecast server can also set up as a relay, where it pulls in from the another server. Primary used to pull the stream

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

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

On 1 Jun 2015, at 16:04, Jack Elliott 541 848 7021 wrote: > 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 true, and it exactly states what's wrong with your syntax. It expects to be a mount name, as mounts will fallback to files in webroot with the same

Simply use VLC and put it on repeat. If a connection is lost during playback, it will reconnect and pick up in the current live position, like you have suggested, without stopping. If it cannot reconnect after 3 times, it goes to the next playlist item. If the playlist is on repeat, it runs indefinitely. Brad Isbell brad at musatcha.com http://www.musatcha.com On Wed, Apr 26, 2017 at 1:58 PM,

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

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

On 14 May 2015, at 18:36, Jack Elliott 541 848 7021 wrote: > 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 just wrote a Wiki page detailing how to install Icecast as service using NSSM, you can find it here http://wiki.xiph.org/Icecast_Server/Setup_Windows_Service