<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>"Live streams are not live, they can be up to 15 to 20 sec off
      original encoding." <br>
    </p>
    <p>Something you become aware of very quickly when you're announcing
      into a mic and have to wait to hear your words! <br>
    </p>
    <p>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. <br>
    </p>
    <p>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. <br>
    </p>
    <p>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.<br>
    </p>
    <p><u>Question</u>: 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.<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
That Jack Elliott
(541) 848 7021
KPOV 88.9 FM High Desert Community radio
Producer, The Wednesday Point
Host, The Sunday Classics
</pre>
    <div class="moz-cite-prefix">On 04/27/2017 08:36 AM, David Saunders
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAOjZz+=1rGKZ8XsUWF1GJ=pRymUkEJuHjxQQqkckH_ZFMp7=Zw@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hey, 
        <div><br>
        </div>
        <div>  Something about streaming.  </div>
        <div> </div>
        <div>        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.</div>
        <div><br>
        </div>
        <div>You can help this by maxing out the following settings: </div>
        queue-size :    This is the buffer you want to  allow the client
        to fall behind.  
        <div>burst-size:        This is how much data you want to fill
          send to the client when they connect to fill up the client
          buffers. </div>
        <div><br>
        </div>
        <div>You can also provide a lower quality stream(lower
          bandwidth) for those who have bad connections.  </div>
        <div><br>
        </div>
        <div> 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. </div>
        <div><br>
        </div>
        <div>  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. </div>
        <div><br>
        </div>
        <div>David.</div>
        <div><br>
          <div><br>
          </div>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Thu, Apr 27, 2017 at 12:58 AM, Jack
          Elliott <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:thatjackelliott@kpov.org" target="_blank">thatjackelliott@kpov.org</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000">
              <p>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.</p>
              <p>For Icecast2 content, when Icecast kicks a client off
                for being "too far behind" -- what is "too far"?<br>
              </p>
              <span class="">
                <pre class="m_2148754537603914082moz-signature" cols="72">-- 
That Jack Elliott
<a moz-do-not-send="true" href="tel:%28541%29%20848-7021" value="+15418487021" target="_blank">(541) 848 7021</a>
KPOV 88.9 FM High Desert Community radio
Producer, The Wednesday Point
Host, The Sunday Classics
</pre>
              </span>
              <div>
                <div class="h5">
                  <div class="m_2148754537603914082moz-cite-prefix">On
                    04/26/2017 08:10 PM, Brad Isbell wrote:<br>
                  </div>
                  <blockquote type="cite">
                    <div dir="ltr">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.<br>
                      <div class="gmail_extra"><br clear="all">
                        <div>
                          <div
                            class="m_2148754537603914082gmail_signature"
                            data-smartmail="gmail_signature">Brad Isbell<br>
                            <a moz-do-not-send="true"
                              href="mailto:brad@musatcha.com"
                              target="_blank">brad@musatcha.com</a><br>
                            <a moz-do-not-send="true"
                              href="http://www.musatcha.com"
                              target="_blank">http://www.musatcha.com</a></div>
                        </div>
                        <br>
                        <div class="gmail_quote">On Wed, Apr 26, 2017 at
                          1:58 PM, Jack Elliott <span dir="ltr"><<a
                              moz-do-not-send="true"
                              href="mailto:thatjackelliott@kpov.org"
                              target="_blank">thatjackelliott@kpov.org</a>></span>
                          wrote:<br>
                          <blockquote class="gmail_quote"
                            style="margin:0 0 0 .8ex;border-left:1px
                            #ccc solid;padding-left:1ex">It's behaving
                            as it is meant to: if a listen client gets
                            too far behind, Icecast2 server is kicking
                            them off.<br>
                            <br>
                            error.log says,<br>
                            <br>
                            "INFO source/source.c Client 120
                            (xxx.xxx.xxx.xxx) has fallen too far behind,
                            removing"<br>
                            <br>
                            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>.<br>
                            <br>
                            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.<br>
                            <br>
                            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.<span
                              class="m_2148754537603914082HOEnZb"><font
                                color="#888888"><br>
                                <br>
                                -- <br>
                                That Jack Elliott<br>
                                <a moz-do-not-send="true"
                                  href="tel:%28541%29%20848%207021"
                                  value="+15418487021" target="_blank">(541)
                                  848 7021</a><br>
                                KPOV 88.9 FM High Desert Community radio<br>
                                Producer, The Wednesday Point<br>
                                Host, The Sunday Classics<br>
                                <br>
                                ______________________________<wbr>_________________<br>
                                Icecast mailing list<br>
                                <a moz-do-not-send="true"
                                  href="mailto:Icecast@xiph.org"
                                  target="_blank">Icecast@xiph.org</a><br>
                                <a moz-do-not-send="true"
                                  href="http://lists.xiph.org/mailman/"
                                  target="_blank">http://lists.xiph.org/mailman/</a><wbr>listinfo/icecast<br>
                              </font></span></blockquote>
                        </div>
                        <br>
                      </div>
                    </div>
                  </blockquote>
                  <br>
                </div>
              </div>
            </div>
            <br>
            ______________________________<wbr>_________________<br>
            Icecast mailing list<br>
            <a moz-do-not-send="true" href="mailto:Icecast@xiph.org">Icecast@xiph.org</a><br>
            <a moz-do-not-send="true"
              href="http://lists.xiph.org/mailman/listinfo/icecast"
              rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/<wbr>listinfo/icecast</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>