Icecast - Apr 2017 - Using Icecast relay function with dynamic IP at remote source end

Hey,

  The relay easiest to configured in a pull configuration. Where the
setting are setup on the remote server.

   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.

  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.

 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.

  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.

David.

On Wed, Apr 19, 2017 at 11:02 AM, Marvin Scholz <epirat07 at gmail.com>
wrote:
>
>
> On 19 Apr 2017, at 16:20, Jack Elliott wrote:
>
> 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.
>>
>> REMOTE LOCATION                        STATION BUILDING
>> B.U.T.T.         ======= WAN =======>> ICECAST SERVER
>>
>> It's pretty reliable, though BUTT does sometimes lose connection,
>> probably due to network congestion.
>>
>> 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:
>>
>> REMOTE LOCATION                                    STATION BUILDING
>> B.U.T.T. --> Icecast on localhost  ==== WAN ====>> ICECAST
SERVER
>>
>
> I am not sure how this could be more reliable than BUTT alone.
>
>
>> I'm finding the terminology for setting up a relay (on
>> http://icecast.org/docs/icecast-2.4.0/config-file.html#relay) to be a
>> bit confusing and could use some help.
>>
>> 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.
>>
>> 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."
>>
>> 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.
>>
>> I hope this question makes sense. My confusion is clearly because I am
>> unclear which server (remote or building) the <relay> section
applies to.
>>
>> --
>> 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/20170419/9e99ad5e/attachment.html>

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.

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.

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.

Here's how I've been doing it:

BUTT --> localhost Icecast server ===> WAN ===> Icecast server

I thought I might try this instead:

BUTT ===> WAN ===> Icecast server

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.

So in my case, the "remote" is at the music festival - my audio
source.

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?

I am puzzled by "pull," since I am wanting to send audio from me to
the
station, but that's pulling?

-- 
That Jack Elliott
(541) 848 7021
KPOV 88.9 FM High Desert Community radio
Producer, The Wednesday Point
Host, The Sunday Classics

On 4/19/2017 10:26 AM, David Saunders wrote:
> Hey,
>
>   The relay easiest to configured in a pull configuration. Where the 
> setting are setup on the remote server.
>
>    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.
>
>   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.
>
>  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.
>
>   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.
>
> David.
>
> On Wed, Apr 19, 2017 at 11:02 AM, Marvin Scholz <epirat07 at gmail.com 
> <mailto:epirat07 at gmail.com>> wrote:
>
>
>
>     On 19 Apr 2017, at 16:20, Jack Elliott wrote:
>
>         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.
>
>         REMOTE LOCATION                        STATION BUILDING
>         B.U.T.T.         ======= WAN =======>> ICECAST SERVER
>
>         It's pretty reliable, though BUTT does sometimes lose
>         connection, probably due to network congestion.
>
>         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:
>
>         REMOTE LOCATION                                    STATION
>         BUILDING
>         B.U.T.T. --> Icecast on localhost  ==== WAN ====>> ICECAST
SERVER
>
>
>     I am not sure how this could be more reliable than BUTT alone.
>
>
>         I'm finding the terminology for setting up a relay (on
>         http://icecast.org/docs/icecast-2.4.0/config-file.html#relay
>        
<http://icecast.org/docs/icecast-2.4.0/config-file.html#relay>)
>         to be a bit confusing and could use some help.
>
>         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.
>
>         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."
>
>         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.
>
>         I hope this question makes sense. My confusion is clearly
>         because I am unclear which server (remote or building) the
>         <relay> section applies to.
>
>         -- 
>         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
>         <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>
>
>
>
>
> _______________________________________________
> 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/20170419/cd435f18/attachment-0001.html>

/I made an error, I swapped two diagrams, it should be this:/

Here's how I've been doing it:

BUTT ===> WAN ===> Icecast server

I thought I might try this instead:

BUTT --> localhost Icecast server ===> WAN ===> Icecast server

-- 
That Jack Elliott
(541) 848 7021
KPOV 88.9 FM High Desert Community radio
Producer, The Wednesday Point
Host, The Sunday Classics

On 4/19/2017 4:00 PM, Jack Elliott wrote:
>
> 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.
>
> 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.
>
> 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.
>
> Here's how I've been doing it:
>
> BUTT --> localhost Icecast server ===> WAN ===> Icecast server
>
> I thought I might try this instead:
>
> BUTT ===> WAN ===> Icecast server
>
> 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.
>
> So in my case, the "remote" is at the music festival - my audio
source.
>
> 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?
>
> I am puzzled by "pull," since I am wanting to send audio from me
to
> the station, but that's pulling?
>
> -- 
> That Jack Elliott
> (541) 848 7021
> KPOV 88.9 FM High Desert Community radio
> Producer, The Wednesday Point
> Host, The Sunday Classics
> On 4/19/2017 10:26 AM, David Saunders wrote:
>> Hey,
>>
>>   The relay easiest to configured in a pull configuration. Where the 
>> setting are setup on the remote server.
>>
>>    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.
>>
>>   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.
>>
>>  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.
>>
>>   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.
>>
>> David.
>>
>> On Wed, Apr 19, 2017 at 11:02 AM, Marvin Scholz <epirat07 at
gmail.com
>> <mailto:epirat07 at gmail.com>> wrote:
>>
>>
>>
>>     On 19 Apr 2017, at 16:20, Jack Elliott wrote:
>>
>>         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.
>>
>>         REMOTE LOCATION                        STATION BUILDING
>>         B.U.T.T.         ======= WAN =======>> ICECAST SERVER
>>
>>         It's pretty reliable, though BUTT does sometimes lose
>>         connection, probably due to network congestion.
>>
>>         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:
>>
>>         REMOTE LOCATION STATION BUILDING
>>         B.U.T.T. --> Icecast on localhost  ==== WAN ====>>
ICECAST SERVER
>>
>>
>>     I am not sure how this could be more reliable than BUTT alone.
>>
>>
>>         I'm finding the terminology for setting up a relay (on
>>         http://icecast.org/docs/icecast-2.4.0/config-file.html#relay
>>        
<http://icecast.org/docs/icecast-2.4.0/config-file.html#relay>)
>>         to be a bit confusing and could use some help.
>>
>>         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.
>>
>>         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."
>>
>>         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.
>>
>>         I hope this question makes sense. My confusion is clearly
>>         because I am unclear which server (remote or building) the
>>         <relay> section applies to.
>>
>>         -- 
>>         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
>>         <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>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20170419/c50a63d1/attachment.html>