<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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 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>
</body></html>