<div dir="ltr">Yes, <div><br></div><div>   Icecast server can run on the lowest of computers. We had a pare of 2nd hand dell server class computers running for close to 10 years streaming for us tell recently when the computers died. And replaced them with another 2nd server class computer. I find I feel safer with a slightly better build computer built for business. Even tho I running icecast at home on a old desktop computer I have had for just about as long. The server can run on top of Linux, and that will run on most anything.  This is why we chose it because it was low overhead and upkeep.</div><div><br></div><div>The only hard requirement that people forget about is the bandwidth needed to host the streams. We used to run on 2 cable connections with 1M uplinks, in those days we used up to 10 relays servers. Since the relay servers only could handle a push I setup VLC/darkice to push it to the server.  Now days we moved on to FIOS/fiber with 100M uplink, and moved all the hosting back into house with overflow pushed to relays when needed.  </div><div><br></div><div>We are looking into streaming live video, still a work in progress to find a good solution that will fit in with our needs.</div><div><br></div><div>David.</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 20, 2017 at 7:50 PM, Jack Elliott <span dir="ltr"><<a 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>Right, BUTT can be set to push to studio, and studio's IP is
      fixed. <br>
    </p>
    <p>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. <br>
    </p>
    <p>Plus, when you are recording eight bands in a 12-hour broadcast
      day, BUTT's ability to stop the local dump-file/recording, save
      it, and start a new recording with a different name, all without
      stopping the stream, is a real plus when all those bands want
      recordings of their sets. Darkice has to be stopped and a new
      dump-file name put into the config file for each band, which kills
      the stream and makes listeners sad. Or you get back to the station
      with a 12-hour-long mp3 that you have to edit down into band-set
      lengths. <br>
    </p>
    <p>That said, at the station, where we are running BUTT on a very
      low-horsepower Linux box to send the station's "Listen Live"
      stream to our Icecast hosting company, I am considering using
      Darkice + Icecast on a Raspberry Pi 3 which has more than enough
      horsepower for that function. The station has a fixed IP so we can
      point their Slave to our Master. <br>
    </p>
    <p>Thanks for all the tips here. <br>
    </p>
    <pre class="m_1479251322265884063moz-signature" cols="72">-- 
That Jack Elliott
<a href="tel:(541)%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_1479251322265884063moz-cite-prefix">On 4/20/2017 4:30 PM, Robert Jeffares
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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="m_1479251322265884063moz-cite-prefix">On 21/04/17 11:05, Jack Elliott
        wrote:<br>
      </div>
      <blockquote type="cite">
        
        <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="m_1479251322265884063moz-signature" cols="72">-- 
That Jack Elliott
<a href="tel:(541)%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_1479251322265884063moz-cite-prefix">On 4/19/2017 8:47 PM, David
          Saunders wrote:<br>
        </div>
        <blockquote 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 href="http://icecast.org/docs/icecast-2.4.1/relaying.html" target="_blank">http://icecast.org/docs/<wbr>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 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_1479251322265884063m_3588810320712558112moz-signature" cols="72">-- 
That Jack Elliott
<a 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_1479251322265884063m_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_1479251322265884063m_3588810320712558112moz-signature" cols="72">-- 
That Jack Elliott
<a 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_1479251322265884063m_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 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 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 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 href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a><br>
                              <a 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 href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a><br>
                            <a 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_1479251322265884063m_3588810320712558112mimeAttachmentHeader"></fieldset>
                      <br>
                      <pre>______________________________<wbr>_________________
Icecast mailing list
<a class="m_1479251322265884063m_3588810320712558112moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a>
<a class="m_1479251322265884063m_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_1479251322265884063m_3588810320712558112mimeAttachmentHeader"></fieldset>
      

      <pre>______________________________<wbr>_________________
Icecast mailing list
<a class="m_1479251322265884063m_3588810320712558112moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a>
<a class="m_1479251322265884063m_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 href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a>

<a 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="m_1479251322265884063mimeAttachmentHeader"></fieldset>
<pre>______________________________<wbr>_________________
Icecast mailing list
<a class="m_1479251322265884063moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a>
<a class="m_1479251322265884063moz-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_1479251322265884063mimeAttachmentHeader"></fieldset>
<pre>______________________________<wbr>_________________
Icecast mailing list
<a class="m_1479251322265884063moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a>
<a class="m_1479251322265884063moz-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 class="m_1479251322265884063moz-signature">-- 
<b>Communication Consultants</b>

64 Warner Park Avenue 


Laingholm 


Auckland 0604


09 8176358


0221693124


06 650 6087

</div>

<fieldset class="m_1479251322265884063mimeAttachmentHeader"></fieldset>
<pre>______________________________<wbr>_________________
Icecast mailing list
<a class="m_1479251322265884063moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a>
<a class="m_1479251322265884063moz-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><br>______________________________<wbr>_________________<br>
Icecast mailing list<br>
<a href="mailto:Icecast@xiph.org">Icecast@xiph.org</a><br>
<a 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>