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 is "too far"? -- That Jack Elliott (541) 848 7021 KPOV 88.9 FM High Desert Community radio Producer, The Wednesday Point Host, The Sunday Classics On 04/26/2017 08:10 PM, Brad Isbell wrote:> 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 <mailto:brad at musatcha.com> > http://www.musatcha.com > > On Wed, Apr 26, 2017 at 1:58 PM, Jack Elliott > <thatjackelliott at kpov.org <mailto:thatjackelliott at kpov.org>> wrote: > > 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 could dump the buffer and bring the listen-client > back up to date instead of dumping the client. The reason being > that when network congestion causes Icecast to kick my > listen-client off, the client application just gives up. And this > is a listen-client I'd like to have running 24/7 so I can monitor > the station's backroom server when we are doing all-day music remotes. > > I haven't found a media/url player that attempts re-connect when > kicked off. At least under Linux. On Windows a player called AIMP3 > works great: if it is disconnected from the server, it tries to > reconnect. Over and over and over. I like that behavior. > > -- > That Jack Elliott > (541) 848 7021 <tel:%28541%29%20848%207021> > KPOV 88.9 FM High Desert Community radio > Producer, The Wednesday Point > Host, The Sunday Classics > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org <mailto:Icecast at xiph.org> > http://lists.xiph.org/mailman/listinfo/icecast > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20170426/e50446cf/attachment.html>
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 server decides I
have no more buffer t back into and drops them. This can be really
pronounced if the connection jumps through a satellite.
You can help this by maxing out the following settings:
queue-size : This is the buffer you want to allow the client to fall
behind.
burst-size: This is how much data you want to fill send to the
client when they connect to fill up the client buffers.
You can also provide a lower quality stream(lower bandwidth) for those who
have bad connections.
What I do is if we get allot of slow listeners, I go though the log
determined how many unique one are falling out of the queue. And tweak up
the queue size or offer a lower quality connection to them when they
connect again :) Since we from time to time have issues with connection
spammers. (They connect to the server 1000/sec, and the slow listens sky
rocket) I use a php traffic controller and black list on the icecast server
to insure the best experience for our listeners.
Just remember, setup the streams at the lowest possible encoding as you
can. There are people who still are not on broadband connections around
the world.
David.
On Thu, Apr 27, 2017 at 12:58 AM, Jack Elliott <thatjackelliott at
kpov.org>
wrote:
> 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 is "too far"?
>
> --
> That Jack Elliott(541) 848 7021 <(541)%20848-7021>
> KPOV 88.9 FM High Desert Community radio
> Producer, The Wednesday Point
> Host, The Sunday Classics
>
> On 04/26/2017 08:10 PM, Brad Isbell wrote:
>
> 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, Jack Elliott <thatjackelliott at
kpov.org>
> wrote:
>
>> 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 could dump the buffer and bring the listen-client back
up
>> to date instead of dumping the client. The reason being that when
network
>> congestion causes Icecast to kick my listen-client off, the client
>> application just gives up. And this is a listen-client I'd like to
have
>> running 24/7 so I can monitor the station's backroom server when we
are
>> doing all-day music remotes.
>>
>> I haven't found a media/url player that attempts re-connect when
kicked
>> off. At least under Linux. On Windows a player called AIMP3 works
great: if
>> it is disconnected from the server, it tries to reconnect. Over and
over
>> and over. I like that behavior.
>>
>> --
>> That Jack Elliott
>> (541) 848 7021
>> KPOV 88.9 FM High Desert Community radio
>> Producer, The Wednesday Point
>> Host, The Sunday Classics
>>
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>>
>
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20170427/bf1b5204/attachment.html>
"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 our remote announcing that
number of seconds before the start of the show so they come out of the
buffers at the right time. And at the end of the remote's broadcast day,
we do the same as latency tends to build up over the period of the show.
We often say, "and thank you for listening," a full 30 seconds before
the scheduled end of the remote so that the studio programming can take
over at the scheduled time.
For our setup there are two listen-clients: we knuckleheads monitoring
at the remote event, and a listen-client at the studio, which feeds the
broadcast console and thence to our radio listeners. The listen client
at the station won't fall too far behind because it's on the same LAN as
the Icecast server. It's us knuckleheads out at the remote, checking in
with the stream to assure that our stream is getting to the server, who
can get kicked off due to falling too far behind.
For music-grade stereo sound we encode to 192kbps mp3. Ogg might be
better-sounding, but they use iTunes and/or Windows Media Player at the
station to play the stream and mp3 is your lowest common denominator.
They fear change at the studio.
_Question_: can the icecast server be set up with two listen-client
mountpoints? Both using the same source-client mountpoint, with one
listen-client mountpoint for studio playback at the encoded bitrate, and
a second listen-client mountpoint re-encoded to a lower bitrate for us
knuckleheads to use at the remote end to monitor? That may add
additional latency for the re-encoding but it might be more reliable.
--
That Jack Elliott
(541) 848 7021
KPOV 88.9 FM High Desert Community radio
Producer, The Wednesday Point
Host, The Sunday Classics
On 04/27/2017 08:36 AM, David Saunders wrote:> 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 server decides I have no more buffer t back into and
> drops them. This can be really pronounced if the connection jumps
> through a satellite.
>
> You can help this by maxing out the following settings:
> queue-size : This is the buffer you want to allow the client to
> fall behind.
> burst-size: This is how much data you want to fill send to the
> client when they connect to fill up the client buffers.
>
> You can also provide a lower quality stream(lower bandwidth) for those
> who have bad connections.
>
> What I do is if we get allot of slow listeners, I go though the log
> determined how many unique one are falling out of the queue. And
> tweak up the queue size or offer a lower quality connection to them
> when they connect again :) Since we from time to time have issues
> with connection spammers. (They connect to the server 1000/sec, and
> the slow listens sky rocket) I use a php traffic controller and black
> list on the icecast server to insure the best experience for our
> listeners.
>
> Just remember, setup the streams at the lowest possible encoding as
> you can. There are people who still are not on broadband connections
> around the world.
>
> David.
>
>
>
> On Thu, Apr 27, 2017 at 12:58 AM, Jack Elliott
> <thatjackelliott at kpov.org <mailto:thatjackelliott at
kpov.org>> wrote:
>
> 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 is "too far"?
>
> --
> That Jack Elliott
> (541) 848 7021 <tel:%28541%29%20848-7021>
> KPOV 88.9 FM High Desert Community radio
> Producer, The Wednesday Point
> Host, The Sunday Classics
>
> On 04/26/2017 08:10 PM, Brad Isbell wrote:
>> 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 <mailto:brad at musatcha.com>
>> http://www.musatcha.com
>>
>> On Wed, Apr 26, 2017 at 1:58 PM, Jack Elliott
>> <thatjackelliott at kpov.org <mailto:thatjackelliott at
kpov.org>> wrote:
>>
>> 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 could dump the buffer and bring the
>> listen-client back up to date instead of dumping the client.
>> The reason being that when network congestion causes Icecast
>> to kick my listen-client off, the client application just
>> gives up. And this is a listen-client I'd like to have
>> running 24/7 so I can monitor the station's backroom server
>> when we are doing all-day music remotes.
>>
>> I haven't found a media/url player that attempts re-connect
>> when kicked off. At least under Linux. On Windows a player
>> called AIMP3 works great: if it is disconnected from the
>> server, it tries to reconnect. Over and over and over. I like
>> that behavior.
>>
>> --
>> That Jack Elliott
>> (541) 848 7021 <tel:%28541%29%20848%207021>
>> KPOV 88.9 FM High Desert Community radio
>> Producer, The Wednesday Point
>> Host, The Sunday Classics
>>
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org <mailto:Icecast at xiph.org>
>> http://lists.xiph.org/mailman/listinfo/icecast
>>
>>
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org <mailto:Icecast at xiph.org>
> http://lists.xiph.org/mailman/listinfo/icecast
> <http://lists.xiph.org/mailman/listinfo/icecast>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20170428/39e42c28/attachment.html>