Jack Elliott
2017-Apr-20 23:05 UTC
[Icecast] Using Icecast relay function with dynamic IP at remote source end
Ha! Terms even a broadcaster can understand! Many many thanks. 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." 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. Is there any way to "push" a connection from Master to Slave? Slave is at a fixed IP address. -- 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 8:47 PM, David Saunders wrote:> ok let see if I can translate it to broadcaster terms for ya :) > > 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. > > 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. > > But, BUTT is designed to stream to an icecast server, and does very well. > > > http://icecast.org/docs/icecast-2.4.1/relaying.html > > 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. > > BUTT ---MASTER ========= SLAVE ===== Clients > --- can be local host or lan or wan private or public > > == is public connections wans/lans/... > > If you need more bandwidth you can setup/rent other SLAVEs on other > networks to augment you bandwidth. > > 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. > > 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. > > Lot of the extra above fore those reading this and nee d a little more > clarity :) > David > > > SLAVE looks a the master waiting for something to do. When it sees the > mount it relays it. > > > > On Wed, Apr 19, 2017 at 7:33 PM, Jack Elliott > <thatjackelliott at kpov.org <mailto:thatjackelliott at kpov.org>> wrote: > > /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 <tel:%28541%29%20848-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 <tel:%28541%29%20848-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 <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 <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/20170420/765375fd/attachment-0001.html>
Robert Jeffares
2017-Apr-20 23:30 UTC
[Icecast] Using Icecast relay function with dynamic IP at remote source end
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 On 21/04/17 11:05, Jack Elliott wrote:> > Ha! Terms even a broadcaster can understand! Many many thanks. > > 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." > > 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. > > Is there any way to "push" a connection from Master to Slave? Slave is > at a fixed IP address. > > -- > 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 8:47 PM, David Saunders wrote: >> ok let see if I can translate it to broadcaster terms for ya :) >> >> 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. >> >> 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. >> >> But, BUTT is designed to stream to an icecast server, and does very >> well. >> >> >> http://icecast.org/docs/icecast-2.4.1/relaying.html >> >> 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. >> >> BUTT ---MASTER ========= SLAVE ===== Clients >> --- can be local host or lan or wan private or public >> >> == is public connections wans/lans/... >> >> If you need more bandwidth you can setup/rent other SLAVEs on other >> networks to augment you bandwidth. >> >> 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. >> >> 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. >> >> Lot of the extra above fore those reading this and nee d a little >> more clarity :) >> David >> >> >> SLAVE looks a the master waiting for something to do. When it sees >> the mount it relays it. >> >> >> >> On Wed, Apr 19, 2017 at 7:33 PM, Jack Elliott >> <thatjackelliott at kpov.org <mailto:thatjackelliott at kpov.org>> wrote: >> >> /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 <tel:%28541%29%20848-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 <tel:%28541%29%20848-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 <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 <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-- *Communication Consultants* 64 Warner Park Avenue Laingholm Auckland 0604 09 8176358 0221693124 06 650 6087 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20170421/7f72d9bf/attachment-0001.html>
Jack Elliott
2017-Apr-20 23:50 UTC
[Icecast] Using Icecast relay function with dynamic IP at remote source end
Right, BUTT can be set to push to studio, and studio's IP is fixed. 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. 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. 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. Thanks for all the tips here. -- That Jack Elliott (541) 848 7021 KPOV 88.9 FM High Desert Community radio Producer, The Wednesday Point Host, The Sunday Classics On 4/20/2017 4:30 PM, Robert Jeffares wrote:> > > 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 > > > On 21/04/17 11:05, Jack Elliott wrote: >> >> Ha! Terms even a broadcaster can understand! Many many thanks. >> >> 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." >> >> 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. >> >> Is there any way to "push" a connection from Master to Slave? Slave >> is at a fixed IP address. >> >> -- >> 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 8:47 PM, David Saunders wrote: >>> ok let see if I can translate it to broadcaster terms for ya :) >>> >>> 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. >>> >>> 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. >>> >>> But, BUTT is designed to stream to an icecast server, and does very >>> well. >>> >>> >>> http://icecast.org/docs/icecast-2.4.1/relaying.html >>> >>> 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. >>> >>> BUTT ---MASTER ========= SLAVE ===== Clients >>> --- can be local host or lan or wan private or public >>> >>> == is public connections wans/lans/... >>> >>> If you need more bandwidth you can setup/rent other SLAVEs on other >>> networks to augment you bandwidth. >>> >>> 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. >>> >>> 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. >>> >>> Lot of the extra above fore those reading this and nee d a little >>> more clarity :) >>> David >>> >>> >>> SLAVE looks a the master waiting for something to do. When it sees >>> the mount it relays it. >>> >>> >>> >>> On Wed, Apr 19, 2017 at 7:33 PM, Jack Elliott >>> <thatjackelliott at kpov.org <mailto:thatjackelliott at kpov.org>> wrote: >>> >>> /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 <tel:%28541%29%20848-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 <tel:%28541%29%20848-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 <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 <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 > -- *Communication Consultants* 64 Warner Park Avenue Laingholm > Auckland 0604 09 8176358 0221693124 06 650 6087 > > _______________________________________________ > 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/20170420/47e7eb89/attachment-0001.html>
David Saunders
2017-Apr-21 12:14 UTC
[Icecast] Using Icecast relay function with dynamic IP at remote source end
Hey, Yes, we been just using a simple source client connecting directly to our icecast server for years. These being a simple free solution. Also works with other free and paid for products too. Your milage will varry with each program, and what features it will offers. For dynamic IPs you can use a service like noip.com. There are a few of them to choose from. IT allow you to give your machine on the dynamic ip a host name so you can find it. Another good solution is use a telephone interface. Depending on the telephone interface you either can have it source to icecast if it can or let BUTT encode it then pass it to the icecast server. We found this is good for filling in gaps where good internet connection is not available. But you will loose some fidelity using the phone tho. I have found tring to stream though a telephone data connection is a hit or miss, to much depends of the carrier. David. On Thu, Apr 20, 2017 at 7:05 PM, Jack Elliott <thatjackelliott at kpov.org> wrote:> Ha! Terms even a broadcaster can understand! Many many thanks. > > 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." > > 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. > > Is there any way to "push" a connection from Master to Slave? Slave is at > a fixed IP address. > > -- > That Jack Elliott(541) 848 7021 <(541)%20848-7021> > KPOV 88.9 FM High Desert Community radio > Producer, The Wednesday Point > Host, The Sunday Classics > > On 4/19/2017 8:47 PM, David Saunders wrote: > > ok let see if I can translate it to broadcaster terms for ya :) > > 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. > > 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. > > But, BUTT is designed to stream to an icecast server, and does very well. > > > http://icecast.org/docs/icecast-2.4.1/relaying.html > > 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. > > BUTT ---MASTER ========= SLAVE ===== Clients > --- can be local host or lan or wan private or public > > == is public connections wans/lans/... > > If you need more bandwidth you can setup/rent other SLAVEs on other > networks to augment you bandwidth. > > 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. > > 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. > > Lot of the extra above fore those reading this and nee d a little more > clarity :) > David > > > SLAVE looks a the master waiting for something to do. When it sees the > mount it relays it. > > > > On Wed, Apr 19, 2017 at 7:33 PM, Jack Elliott <thatjackelliott at kpov.org> > wrote: > >> *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 <%28541%29%20848-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 <%28541%29%20848-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> >> 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 <%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 >>>> http://lists.xiph.org/mailman/listinfo/icecast >>>> >>> _______________________________________________ >>> Icecast mailing list >>> Icecast at xiph.org >>> http://lists.xiph.org/mailman/listinfo/icecast >>> >> >> >> >> _______________________________________________ >> Icecast mailing listIcecast at xiph.orghttp://lists.xiph.org/mailman/listinfo/icecast >> >> _______________________________________________ >> Icecast mailing listIcecast at xiph.orghttp://lists.xiph.org/mailman/listinfo/icecast >> >> _______________________________________________ Icecast mailing list >> Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast > > _______________________________________________ > Icecast mailing listIcecast at xiph.orghttp://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/20170421/f0c71ca1/attachment-0001.html>
Jack Elliott
2017-Apr-23 15:16 UTC
[Icecast] SOLVED Using Icecast relay function with dynamic IP at remote source end
Thanks, all, for chiming in on this thread. I've solved the problem that prompted me to start it, which was several disconnects/reconnects per day between our music festival remote's BUTT source client and the station's backstream Icecast server. I was looking at everything including using another encoder client and different transport methods (icecast <-> icecast, prompting this thread) and using mtr and other free tools to try to tease out whether massive network congestion was responsible. What turned out to be responsible for the frequent disconnects was a setting in icecast's config file. I thought to look at icecast's error.log and found one of the disconnects, having to do with source client timeout. I googled that error message and it lead me to a discussion somewhere online about the <source-timeout> setting in icecast.xml. I found that ours was set to 1 second instead of the default 10 seconds. I changed it back to the default (which incidentally is also the default used by Streamguys, the public listener stream hosting company the station uses) and Hey Presto! no more dropouts. Impressive to me that even with a dozen hops between the butt source client (presently at my house) and the station's icecast server, there were only a handful of dropouts per day with a 1-second setting. 10 seconds is gonna be pretty robust, I think. -- That Jack Elliott (541) 848 7021 KPOV 88.9 FM High Desert Community radio Producer, The Wednesday Point Host, The Sunday Classics
Reasonably Related Threads
- Using Icecast relay function with dynamic IP at remote source end
- Using Icecast relay function with dynamic IP at remote source end
- Using Icecast relay function with dynamic IP at remote source end
- Using Icecast relay function with dynamic IP at remote source end
- Using Icecast relay function with dynamic IP at remote source end