<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
      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 </p>
    <br>
    <div class="moz-cite-prefix">On 21/04/17 11:05, Jack Elliott wrote:<br>
    </div>
    <blockquote cite="mid:399d416c-29c8-e7a1-d12c-8a9fe4be3c4b@kpov.org"
      type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      <p>Ha! Terms even a broadcaster can understand! Many many thanks.</p>
      <p>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."</p>
      <p>Slave may not know where the Master is. Master (on a table in
        front of me at a remote music event) may be at unknown/dynamic
        IP address. I'd have to find my IP address, Teamview into the
        server computer at the station, stop the Icecast service, edit
        icecast.xml with my current IP address, and re-start the Icecast
        service. <br>
      </p>
      <p>Is there any way to "push" a connection from Master to Slave?
        Slave is at a fixed IP address. <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 4/19/2017 8:47 PM, David Saunders
        wrote:<br>
      </div>
      <blockquote
cite="mid:CAOjZz+n0SSCU-oA6AM5Atc6pQO=4G9qWoKA9qKkLK5rbtc7rMw@mail.gmail.com"
        type="cite">
        <div dir="ltr">ok let see if I can translate it to broadcaster
          terms for ya :) 
          <div><br>
          </div>
          <div>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.  </div>
          <div><br>
          </div>
          <div>THe icecast server can also set up as a relay, where it
            pulls in from the another server.  Primary used to pull the
            stream from a icecast server. Then make it available to be
            acceded by clients from it mounts.  </div>
          <div><br>
          </div>
          <div>But, BUTT is designed to stream to an icecast server, and
            does very well.  </div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div><a moz-do-not-send="true"
              href="http://icecast.org/docs/icecast-2.4.1/relaying.html">http://icecast.org/docs/icecast-2.4.1/relaying.html</a><br>
          </div>
          <div><br>
          </div>
          <div>Master is the source server (where the source comes from)
            ad Slave is the relay. THe connection is initiated by the
            slave to the master. </div>
          <div><br>
          </div>
          <div>BUTT ---MASTER ========= SLAVE ===== Clients</div>
          <div>--- can be local host or lan or wan  private or public </div>
          <div><br>
          </div>
          <div>== is public connections wans/lans/...</div>
          <div><br>
          </div>
          <div>If you need more bandwidth you can setup/rent other
            SLAVEs on other networks to augment you bandwidth.</div>
          <div><br>
          </div>
          <div>It lot easier to have 1 master and bunch of slaves to
            spreading the bandwidth out,  It easier to maintain a single
            master with many mounts + it easy to trace problems down
            with sources going to a common Master. </div>
          <div><br>
          </div>
          <div>I tend to diverge from your question a bit.   But, your
            encoder should work find with broadcaster to the icecast
            server by itself. I have had it done for the past 10 years.
            The only real issue s when you encode the stream higher then
            what he bandwidth can handle.  remember the source clients
            use the UPLOAD speed of you connection and the client use
            the UPLOAD speeds. In the USA it no uncommon to have uploads
            speeds to be far slower then you can download. Also I am
            talking about how fast the connection is not how much data
            you have in a month. It get really confusing when you talk
            about bandwidth, since they call both bandwidths.One is how
            big your pipe is and other how much you get through the pipe
            in a given time. </div>
          <div><br>
          </div>
          <div>Lot of the extra above fore those reading this and nee d
            a little more clarity :)</div>
          <div>David</div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div>SLAVE looks a the master waiting for something to do.
            When it sees the mount it relays it.</div>
          <div><br>
          </div>
          <div><br>
          </div>
        </div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Wed, Apr 19, 2017 at 7:33 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">
              <div bgcolor="#FFFFFF" text="#000000">
                <p><i>I made an error, I swapped two diagrams, it should
                    be this:</i></p>
                <p>Here's how I've been doing it:<br>
                </p>
                <p><tt>BUTT ===> WAN ===> Icecast server</tt> </p>
                <p>I thought I might try this instead: <br>
                </p>
                <p><tt><tt>BUTT --> localhost Icecast server ===>
                      WAN ===> Icecast server</tt></tt></p>
                <pre class="m_3588810320712558112moz-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>
                <div class="m_3588810320712558112moz-cite-prefix">On
                  4/19/2017 4:00 PM, Jack Elliott wrote:<br>
                </div>
                <blockquote type="cite">
                  <p>Hi David, I don't think we will necessarily be on
                    wifi, I'm sorry if I implied that. There are a
                    couple of events each year when we have to use wifi,
                    but for those I have a dedicated access point
                    running at close to 1 watt connected directly to our
                    ISP's network. <br>
                  </p>
                  <p>Okay, I was told over on the Darkice listserv that
                    using Darkice > WAN > Icecast is not very
                    reliable, and my testing supported that statement.
                    They said that Darkice is an encoder, and Icecast is
                    a transporter. Icecast, they said, is very reliable,
                    Darkice is a good encoder but not too great as a
                    transporter.   <br>
                  </p>
                  <p>I've been using BUTT as the encoder at the remote
                    (audio source) end, and sending the stream over the
                    WAN to the Icecast server at the station building.
                    BUTT, I found, is more reliable than Darkice at the
                    encoding end. <br>
                  </p>
                  <p>Here's how I've been doing it:<br>
                  </p>
                  <p><tt>BUTT --> localhost Icecast server ===>
                      WAN ===> Icecast server</tt><br>
                  </p>
                  <p>I thought I might try this instead: <br>
                  </p>
                  <p><tt>BUTT ===> WAN ===> Icecast server</tt></p>
                  <p>Now here I want to avoid using incorrect
                    terminology. The way I am using the word "remote" is
                    how it is used in broadcast: if a crew leaves the
                    building to broadcast an event occurring outside the
                    station somewhere, they are doing a remote. <br>
                  </p>
                  <p>So in my case, the "remote" is at the music
                    festival - my audio source. <br>
                  </p>
                  <p>So when you write, "The relay easiest to configured
                    in a pull configuration. Where the setting are setup
                    on the remote server." -- is it correct for me to
                    interpret that to mean that I can leave the settings
                    on the station computer's server alone, just set up
                    the server in my remote kit to "pull" from the
                    station's server? <br>
                  </p>
                  <p>I am puzzled by "pull," since I am wanting to send
                    audio from me to the station, but that's pulling? <br>
                  </p>
                  <pre class="m_3588810320712558112moz-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>
                  <div class="m_3588810320712558112moz-cite-prefix">On
                    4/19/2017 10:26 AM, David Saunders wrote:<br>
                  </div>
                  <blockquote type="cite">
                    <div dir="ltr">Hey,
                      <div><br>
                      </div>
                      <div>  The relay easiest to configured in a pull
                        configuration. Where the setting are setup on
                        the remote server.</div>
                      <div><br>
                      </div>
                      <div>   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.</div>
                      <div><br>
                      </div>
                      <div>  We do have clients who use WiFi and set the
                        the encoding to smallest size for the content
                        being recorded. Most of the time since its voice
                        content we really don't have to go super high on
                        the encoding. </div>
                      <div><br>
                      </div>
                      <div> I have set up the relay to supplement our
                        bandwidth when we think it will be over the
                        limit.  Just remember you need to give the
                        listeners the remote server connection info not
                        the local server.  </div>
                      <div><br>
                      </div>
                      <div>  Why it would be better? not sure why, but
                        if the icecast server is set with a larger
                        buffer, it will buffer thru the disconnects of
                        the source. </div>
                      <div><br>
                      </div>
                      <div>David.</div>
                    </div>
                    <div class="gmail_extra"><br>
                      <div class="gmail_quote">On Wed, Apr 19, 2017 at
                        11:02 AM, Marvin Scholz <span dir="ltr"><<a
                            moz-do-not-send="true"
                            href="mailto:epirat07@gmail.com"
                            target="_blank">epirat07@gmail.com</a>></span>
                        wrote:<br>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex"><br>
                          <br>
                          On 19 Apr 2017, at 16:20, Jack Elliott wrote:<br>
                          <br>
                          <blockquote class="gmail_quote"
                            style="margin:0 0 0 .8ex;border-left:1px
                            #ccc solid;padding-left:1ex"> For our
                            community radio station's live music
                            festivals broadcasts, we set up a small
                            broadcast studio at the festival's venue,
                            and use B.U.T.T. to send a stream to an
                            Icecast server located at the radio
                            station's building.<br>
                            <br>
                            REMOTE LOCATION                       
                            STATION BUILDING<br>
                            B.U.T.T.         ======= WAN =======>>
                            ICECAST SERVER<br>
                            <br>
                            It's pretty reliable, though BUTT does
                            sometimes lose connection, probably due to
                            network congestion.<br>
                            <br>
                            The folks on the Darkice listserv claim that
                            using Icecast to do the sending provides a
                            more reliable connection. So I want to try
                            this idea:<br>
                            <br>
                            REMOTE LOCATION                             
                                  STATION BUILDING<br>
                            B.U.T.T. --> Icecast on localhost  ====
                            WAN ====>> ICECAST SERVER<br>
                          </blockquote>
                          <br>
                          I am not sure how this could be more reliable
                          than BUTT alone.<br>
                          <br>
                          <blockquote class="gmail_quote"
                            style="margin:0 0 0 .8ex;border-left:1px
                            #ccc solid;padding-left:1ex"> <br>
                            I'm finding the terminology for setting up a
                            relay (on <a moz-do-not-send="true"
                              href="http://icecast.org/docs/icecast-2.4.0/config-file.html#relay"
                              rel="noreferrer" target="_blank">http://icecast.org/docs/icecas<wbr>t-2.4.0/config-file.html#relay</a><wbr>)
                            to be a bit confusing and could use some
                            help.<br>
                            <br>
                            I believe I want to set up a Specific
                            Mountpoint Relay. It's where the IP
                            addresses get plugged in that I need some
                            clarification. The IP address for the
                            building is static, but the IP address for
                            the remote server is unknown before every
                            festival, and may be dynamic.<br>
                            <br>
                            The documentation says that for the
                            <relay> section of the xml, we have a
                            <server>127.0.0.1</server>
                            setting. And that is described as "This is
                            the IP for the server which contains the
                            mountpoint to be relayed."<br>
                            <br>
                            I can't tell whether the <relay? section
                            is on the remote server, in which case we
                            only need to put the static IP of the
                            building in the <server> section, or
                            whether the <relay> section is on the
                            building's server, in which case we need to
                            know ahead of time what our remote IP will
                            be, and hope it doesn't change during the
                            festival.<br>
                            <br>
                            I hope this question makes sense. My
                            confusion is clearly because I am unclear
                            which server (remote or building) the
                            <relay> section applies to.<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>
                            ______________________________<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/listinfo/icecast"
                              rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/<wbr>listinfo/icecast</a><br>
                          </blockquote>
                          ______________________________<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/listinfo/icecast"
                            rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/<wbr>listinfo/icecast</a><br>
                        </blockquote>
                      </div>
                      <br>
                    </div>
                    <br>
                    <fieldset
                      class="m_3588810320712558112mimeAttachmentHeader"></fieldset>
                    <br>
                    <pre>______________________________<wbr>_________________
Icecast mailing list
<a moz-do-not-send="true" class="m_3588810320712558112moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a>
<a moz-do-not-send="true" class="m_3588810320712558112moz-txt-link-freetext" href="http://lists.xiph.org/mailman/listinfo/icecast" target="_blank">http://lists.xiph.org/mailman/<wbr>listinfo/icecast</a>
</pre>
      </blockquote>
      

      

      <fieldset class="m_3588810320712558112mimeAttachmentHeader"></fieldset>
      

      <pre>______________________________<wbr>_________________
Icecast mailing list
<a moz-do-not-send="true" class="m_3588810320712558112moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a>
<a moz-do-not-send="true" class="m_3588810320712558112moz-txt-link-freetext" href="http://lists.xiph.org/mailman/listinfo/icecast" target="_blank">http://lists.xiph.org/mailman/<wbr>listinfo/icecast</a>
</pre>
    </blockquote>
    

  </div>


______________________________<wbr>_________________

Icecast mailing list

<a moz-do-not-send="true" href="mailto:Icecast@xiph.org">Icecast@xiph.org</a>

<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>


</blockquote></div>
</div>


<fieldset class="mimeAttachmentHeader"></fieldset>
<pre wrap="">_______________________________________________
Icecast mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org">Icecast@xiph.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.xiph.org/mailman/listinfo/icecast">http://lists.xiph.org/mailman/listinfo/icecast</a>
</pre>

</blockquote>


<fieldset class="mimeAttachmentHeader"></fieldset>
<pre wrap="">_______________________________________________
Icecast mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org">Icecast@xiph.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xiph.org/mailman/listinfo/icecast">http://lists.xiph.org/mailman/listinfo/icecast</a>
</pre>

</blockquote>
<div class="moz-signature">-- 
<b>Communication Consultants</b>

64 Warner Park Avenue 


Laingholm 


Auckland 0604


09 8176358


0221693124


06 650 6087

</div></body></html>