From chris at elfpen.com Sat Apr 15 13:19:33 2017 From: chris at elfpen.com (Chris Howard) Date: Sat, 15 Apr 2017 08:19:33 -0500 Subject: [Icecast] help on listener connection stats Message-ID: Hi, I see two statistics on the admin web page. On my system "listeners" is usually 0. Sometimes I will actually catch it at 1 or 2, but it is 0 99% of the time. On the other hand "listener_connections" is always going up. If I refresh the screen it goes up by a few. If I wait an hour and refresh it goes up by tens. Over a few days it goes up by hundreds. What is this telling me? In pursuit of this question I started looking at the logs a little bit. I see a lot of connections happening, particular from a Bose Streaming Service (something like that) which can show 5-6 log entries in one second. What's up with that? Thanks for your help Chris Howard Classic Book Radio wmfh-lp.org From jvoosten at bankai.nl Sat Apr 15 19:56:45 2017 From: jvoosten at bankai.nl (Jeroen van Oosten) Date: Sat, 15 Apr 2017 21:56:45 +0200 Subject: [Icecast] help on listener connection stats In-Reply-To: References: Message-ID: <58F27AFD.1030907@bankai.nl> Hello, On 15-04-17 15:19, Chris Howard wrote: > Hi, > > I see two statistics on the admin web page. > > On my system "listeners" is usually 0. Sometimes I will > actually catch it at 1 or 2, but it is 0 99% of the time. That is the current number of listeners. > On the other hand "listener_connections" is always > going up. If I refresh the screen it goes up by a few. > If I wait an hour and refresh it goes up by tens. > Over a few days it goes up by hundreds. > > What is this telling me? That is the total number of times somebody connected to your stream. If your restart your icecast server you will see that the number drops back to zero. In itself it is not a very useful number, IMO. > In pursuit of this question I started looking at the > logs a little bit. I see a lot of connections > happening, particular from a Bose Streaming Service > (something like that) which can show 5-6 log entries > in one second. What's up with that? Is your station listed in a directory of online radio stations? It could be someone is trying to connect to your stream with their home system or internet radio, but failing to stream it (perhaps it doesn't understand your encoding format). Regards, Jeroen van Oosten -- Bankai Software bv Jeroen van Oosten Telefoon: 088-2344999 E-mail: jvoosten at bankai.nl KvK inschrijving: 67066267 "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair From chris at elfpen.com Sun Apr 16 23:59:06 2017 From: chris at elfpen.com (Chris Howard) Date: Sun, 16 Apr 2017 18:59:06 -0500 Subject: [Icecast] help on listener connection stats In-Reply-To: <58F27AFD.1030907@bankai.nl> References: <58F27AFD.1030907@bankai.nl> Message-ID: <3f0c6c7e-608d-5c69-bde8-6567ca895960@elfpen.com> Thanks for the insight. I'm keeping an eye on my logs and I think I'm getting a better feel for my traffic. I still see "listener_connection" going up for some unknown reason. And the "Bose..." thing seems to connect every hour at around the half-hour mark (x:30) and listen for 10 minutes and then drop off. The IP addresses change but they are all Amazon Web Services in Virginia. I wish I knew what that was about. The regularity of it feels more like a robot of some sort than a real listener. And our programming pattern at the half-hour mark is not anything predictable. Chris Howard wmfh-lp.org On 4/15/2017 2:56 PM, Jeroen van Oosten wrote: > Hello, > > On 15-04-17 15:19, Chris Howard wrote: >> Hi, >> >> I see two statistics on the admin web page. >> >> On my system "listeners" is usually 0. Sometimes I will >> actually catch it at 1 or 2, but it is 0 99% of the time. > > That is the current number of listeners. > >> On the other hand "listener_connections" is always >> going up. If I refresh the screen it goes up by a few. >> If I wait an hour and refresh it goes up by tens. >> Over a few days it goes up by hundreds. >> >> What is this telling me? > That is the total number of times somebody connected to your stream. If > your restart your icecast server you will see that the number drops back > to zero. In itself it is not a very useful number, IMO. > >> In pursuit of this question I started looking at the >> logs a little bit. I see a lot of connections >> happening, particular from a Bose Streaming Service >> (something like that) which can show 5-6 log entries >> in one second. What's up with that? > Is your station listed in a directory of online radio stations? It could > be someone is trying to connect to your stream with their home system or > internet radio, but failing to stream it (perhaps it doesn't understand > your encoding format). > > Regards, > > Jeroen van Oosten > > From un at aporee.org Mon Apr 17 06:40:22 2017 From: un at aporee.org (unosonic) Date: Mon, 17 Apr 2017 08:40:22 +0200 Subject: [Icecast] help on listener connection stats In-Reply-To: <3f0c6c7e-608d-5c69-bde8-6567ca895960@elfpen.com> References: <58F27AFD.1030907@bankai.nl> <3f0c6c7e-608d-5c69-bde8-6567ca895960@elfpen.com> Message-ID: <20170417064022.GA13078@aporee.org> Chris Howard: > > And the "Bose..." thing seems to connect every hour at > around the half-hour mark (x:30) and listen for 10 minutes > and then drop off. The IP addresses change but they > are all Amazon Web Services in Virginia. > I wish I knew what that was about. The regularity of > it feels more like a robot of some sort than a real listener. I see that too, among others. I guess it's sort of proxy/check for availability or so, in order to list that stream on a device's station listing. but don't know for sure though. --u From thatjackelliott at kpov.org Wed Apr 19 14:20:43 2017 From: thatjackelliott at kpov.org (Jack Elliott) Date: Wed, 19 Apr 2017 07:20:43 -0700 Subject: [Icecast] Using Icecast relay function with dynamic IP at remote source end Message-ID: 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'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 section of the xml, we have a 127.0.0.1 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 section, or whether the 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 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 From epirat07 at gmail.com Wed Apr 19 15:02:16 2017 From: epirat07 at gmail.com (Marvin Scholz) Date: Wed, 19 Apr 2017 17:02:16 +0200 Subject: [Icecast] Using Icecast relay function with dynamic IP at remote source end In-Reply-To: References: Message-ID: <2502FCC8-06E3-4759-9E95-A047AFA9296B@gmail.com> 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 section of the xml, we > have a 127.0.0.1 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 which case we only need to put the static IP of the building in the > section, or whether the 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 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 From abitar.com at gmail.com Wed Apr 19 17:26:35 2017 From: abitar.com at gmail.com (David Saunders) Date: Wed, 19 Apr 2017 13:26:35 -0400 Subject: [Icecast] Using Icecast relay function with dynamic IP at remote source end In-Reply-To: <2502FCC8-06E3-4759-9E95-A047AFA9296B@gmail.com> References: <2502FCC8-06E3-4759-9E95-A047AFA9296B@gmail.com> Message-ID: 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 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 section of the xml, we have a >> 127.0.0.1 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 > which case we only need to put the static IP of the building in the >> section, or whether the 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 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: From thatjackelliott at kpov.org Wed Apr 19 23:00:23 2017 From: thatjackelliott at kpov.org (Jack Elliott) Date: Wed, 19 Apr 2017 16:00:23 -0700 Subject: [Icecast] Using Icecast relay function with dynamic IP at remote source end In-Reply-To: References: <2502FCC8-06E3-4759-9E95-A047AFA9296B@gmail.com> Message-ID: <49b14eb3-b666-638d-48a3-06ccd8c9d518@kpov.org> 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 > 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 section of the > xml, we have a 127.0.0.1 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 server, in which case we only need to put the static IP of the > building in the section, or whether the > 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 > 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 > > > > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -------------- next part -------------- An HTML attachment was scrubbed... URL: From thatjackelliott at kpov.org Wed Apr 19 23:33:19 2017 From: thatjackelliott at kpov.org (Jack Elliott) Date: Wed, 19 Apr 2017 16:33:19 -0700 Subject: [Icecast] Using Icecast relay function with dynamic IP at remote source end In-Reply-To: <49b14eb3-b666-638d-48a3-06ccd8c9d518@kpov.org> References: <2502FCC8-06E3-4759-9E95-A047AFA9296B@gmail.com> <49b14eb3-b666-638d-48a3-06ccd8c9d518@kpov.org> Message-ID: /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 > > 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 section of the >> xml, we have a 127.0.0.1 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 > server, in which case we only need to put the static IP of >> the building in the section, or whether the >> 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 >> 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 >> >> >> >> >> >> _______________________________________________ >> 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: From abitar.com at gmail.com Thu Apr 20 03:47:27 2017 From: abitar.com at gmail.com (David Saunders) Date: Wed, 19 Apr 2017 23:47:27 -0400 Subject: [Icecast] Using Icecast relay function with dynamic IP at remote source end In-Reply-To: References: <2502FCC8-06E3-4759-9E95-A047AFA9296B@gmail.com> <49b14eb3-b666-638d-48a3-06ccd8c9d518@kpov.org> Message-ID: 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 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 <(541)%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 <(541)%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 > 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 section of the xml, we have >>> a 127.0.0.1 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 >> which case we only need to put the static IP of the building in the >>> section, or whether the 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 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 >> > > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thatjackelliott at kpov.org Thu Apr 20 23:05:11 2017 From: thatjackelliott at kpov.org (Jack Elliott) Date: Thu, 20 Apr 2017 16:05:11 -0700 Subject: [Icecast] Using Icecast relay function with dynamic IP at remote source end In-Reply-To: References: <2502FCC8-06E3-4759-9E95-A047AFA9296B@gmail.com> <49b14eb3-b666-638d-48a3-06ccd8c9d518@kpov.org> Message-ID: <399d416c-29c8-e7a1-d12c-8a9fe4be3c4b@kpov.org> 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 > > 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 > 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 >>> > 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 section of >>> the xml, we have a 127.0.0.1 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 >> remote server, in which case we only need to put the >>> static IP of the building in the section, or >>> whether the 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 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 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > 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: From jeffares.robert at gmail.com Thu Apr 20 23:30:07 2017 From: jeffares.robert at gmail.com (Robert Jeffares) Date: Fri, 21 Apr 2017 11:30:07 +1200 Subject: [Icecast] Darkice vs BUTT and Icecast In-Reply-To: References: <2502FCC8-06E3-4759-9E95-A047AFA9296B@gmail.com> <49b14eb3-b666-638d-48a3-06ccd8c9d518@kpov.org> Message-ID: <40b1b4b9-eef3-f905-6434-aba2eab461b5@gmail.com> I have spent part of today at a site which uses all of the above programs. A change of mains power service should be more reliable. Recent conversations here prompted this review. We have 2 machines running Darkice & Icecast2 each connected to a fibre service. Darkice is set to provide a high grade aac+ stream for 3 broadcast sites, a rebroadcast / logger [256b] mp3 local recording, and a skinny [56b] mp3 'website' stream. You can shape the mp3 audio with lowpass an highpass options. We have experimented with various formats and have gone with what the majority of players will handle. Everything runs at 48000 which is the native sampling rate of the on board sound cards. One less resampling process saves time and processor capacity. That's 2 Fibre cables in to the site, and 2 ISP's. One or other can fail, and they do, There was once a short period when both were out. We feed 3 broadcast sites and one IP relay site, which runs Icecast2. The relay site is a paid service provider and allows 200 connections. The relay site 'pulls' the audio from the fixed IP at the studio. It is configured and maintained by the service provider. This in turn feeds several relay services, some of them 'free', and a website player. I have no idea what the external links use, but everything works. There are more links than we know about as some just seem to add us to a list. We have a 'popular' programme! I note some of the relay sites resample our audio. The original installation was ADSL and the uplink could not manage 4 clients because ADSL uplinks are really low grade. In fact we think the ISP's were controlling the bandwidth more than they would admit. We used one upload to an IP relay site. Now we have fibre the relay transmitters connect direct. Each darkice machine has a logger which is a script running as an hourly cron job. We use a high sample rate because a number of the live programmes get rebroadcast. The playout machine is limited to wav and mp3. We use BUTT in a laptop connected to a mobile phone as a hotspot for OB's [Remotes] and the G3 uplink is generally good. We are fortunate that the cellular coverage here is mostly very good and very few users occupy the uplink. We have used local ADSL and Fibre. If we have an event where there will be a huge number of people live streaming from their smartphones, which tends to overload the network we make sure we have a non cellular circuit. BUTT feeds one of the studio Icecast2 servers and comes up in the studio on a second computer running Chrome. Audio plays direct into the desk from the #2 computer soundcard. BUTT is simple, works in windows, and its easy to adjust the bit rate to suit the link. It works better with a bit of headroom. Keep the levels down! Avoid processing. Sample as high as possible. The big advantage of this setup is the cost. The darkice/icecast2 machines are old ex lease junk computers we get for next to nothing. Once configured they run with no screen keyboard or mouse. The HP ones have better power supplies. OS and software is free. They reboot and run BUTT runs on Windows which the frontline are comfortable with. Everyone has a laptop. 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 We get around crossovers by arranging presentation to accomodate the audio delay. Darkice handles multiple encoding with ease. Icecast2 does the transportation BUTT is the simple remote origination solution. regards Robert -- *Raupo Radio* 64 Warner Park Avenue Laingholm Auckland 0604 09 8176358 0221693124 06 650 6087 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffares.robert at gmail.com Thu Apr 20 23:30:55 2017 From: jeffares.robert at gmail.com (Robert Jeffares) Date: Fri, 21 Apr 2017 11:30:55 +1200 Subject: [Icecast] Using Icecast relay function with dynamic IP at remote source end In-Reply-To: <399d416c-29c8-e7a1-d12c-8a9fe4be3c4b@kpov.org> References: <2502FCC8-06E3-4759-9E95-A047AFA9296B@gmail.com> <49b14eb3-b666-638d-48a3-06ccd8c9d518@kpov.org> <399d416c-29c8-e7a1-d12c-8a9fe4be3c4b@kpov.org> Message-ID: 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 >> > 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 >> 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 >>>> > 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 section of >>>> the xml, we have a 127.0.0.1 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 >>> remote server, in which case we only need to put the >>>> static IP of the building in the section, or >>>> whether the 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 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 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> 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 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: From thatjackelliott at kpov.org Thu Apr 20 23:50:36 2017 From: thatjackelliott at kpov.org (Jack Elliott) Date: Thu, 20 Apr 2017 16:50:36 -0700 Subject: [Icecast] Using Icecast relay function with dynamic IP at remote source end In-Reply-To: References: <2502FCC8-06E3-4759-9E95-A047AFA9296B@gmail.com> <49b14eb3-b666-638d-48a3-06ccd8c9d518@kpov.org> <399d416c-29c8-e7a1-d12c-8a9fe4be3c4b@kpov.org> Message-ID: <37408c64-c206-f929-7dfb-1b954a399b8e@kpov.org> 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 >>> > 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 >>> 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 >>>>> > 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 section of >>>>> the xml, we have a 127.0.0.1 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 >>>> remote server, in which case we only need to put the >>>>> static IP of the building in the section, or >>>>> whether the 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 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> 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 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: From abitar.com at gmail.com Fri Apr 21 12:14:26 2017 From: abitar.com at gmail.com (David Saunders) Date: Fri, 21 Apr 2017 08:14:26 -0400 Subject: [Icecast] Using Icecast relay function with dynamic IP at remote source end In-Reply-To: <399d416c-29c8-e7a1-d12c-8a9fe4be3c4b@kpov.org> References: <2502FCC8-06E3-4759-9E95-A047AFA9296B@gmail.com> <49b14eb3-b666-638d-48a3-06ccd8c9d518@kpov.org> <399d416c-29c8-e7a1-d12c-8a9fe4be3c4b@kpov.org> Message-ID: 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 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 > 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 >> 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 section of the xml, we have >>>> a 127.0.0.1 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 >>> which case we only need to put the static IP of the building in the >>>> section, or whether the 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 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: From abitar.com at gmail.com Fri Apr 21 12:44:00 2017 From: abitar.com at gmail.com (David Saunders) Date: Fri, 21 Apr 2017 08:44:00 -0400 Subject: [Icecast] Using Icecast relay function with dynamic IP at remote source end In-Reply-To: <37408c64-c206-f929-7dfb-1b954a399b8e@kpov.org> References: <2502FCC8-06E3-4759-9E95-A047AFA9296B@gmail.com> <49b14eb3-b666-638d-48a3-06ccd8c9d518@kpov.org> <399d416c-29c8-e7a1-d12c-8a9fe4be3c4b@kpov.org> <37408c64-c206-f929-7dfb-1b954a399b8e@kpov.org> Message-ID: Yes, 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. 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. We are looking into streaming live video, still a work in progress to find a good solution that will fit in with our needs. David. On Thu, Apr 20, 2017 at 7:50 PM, Jack Elliott wrote: > 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 <(541)%20848-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 <(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 > 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 >> 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 section of the xml, we have >>>> a 127.0.0.1 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 >>> which case we only need to put the static IP of the building in the >>>> section, or whether the 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 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 listIcecast at xiph.orghttp://lists.xiph.org/mailman/listinfo/icecast > > -- *Communication Consultants* 64 Warner Park Avenue Laingholm Auckland > 0604 09 8176358 0221693124 06 650 6087 > > _______________________________________________ > 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: From thatjackelliott at kpov.org Sun Apr 23 15:16:44 2017 From: thatjackelliott at kpov.org (Jack Elliott) Date: Sun, 23 Apr 2017 08:16:44 -0700 Subject: [Icecast] SOLVED Using Icecast relay function with dynamic IP at remote source end In-Reply-To: References: <2502FCC8-06E3-4759-9E95-A047AFA9296B@gmail.com> <49b14eb3-b666-638d-48a3-06ccd8c9d518@kpov.org> <399d416c-29c8-e7a1-d12c-8a9fe4be3c4b@kpov.org> Message-ID: 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 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 From thatjackelliott at kpov.org Wed Apr 26 20:58:44 2017 From: thatjackelliott at kpov.org (Jack Elliott) Date: Wed, 26 Apr 2017 13:58:44 -0700 Subject: [Icecast] Server kicking clients off Message-ID: It's behaving as it is meant to: if a listen client gets too far behind, Icecast2 server is kicking them off. error.log says, "INFO source/source.c Client 120 (xxx.xxx.xxx.xxx) has fallen too far behind, removing" I don't see a setting in icecast.xml that sets the value for "too far behind". I'm guessing it's related to . I wish Icecast could dump the buffer and bring the listen-client back up to date instead of dumping the client. The reason being that when network congestion causes Icecast to kick my listen-client off, the client application just gives up. And this is a listen-client I'd like to have running 24/7 so I can monitor the station's backroom server when we are doing all-day music remotes. I haven't found a media/url player that attempts re-connect when kicked off. At least under Linux. On Windows a player called AIMP3 works great: if it is disconnected from the server, it tries to reconnect. Over and over and over. I like that behavior. -- That Jack Elliott (541) 848 7021 KPOV 88.9 FM High Desert Community radio Producer, The Wednesday Point Host, The Sunday Classics From brad at musatcha.com Thu Apr 27 03:10:34 2017 From: brad at musatcha.com (Brad Isbell) Date: Wed, 26 Apr 2017 20:10:34 -0700 Subject: [Icecast] Server kicking clients off In-Reply-To: References: Message-ID: Simply use VLC and put it on repeat. If a connection is lost during playback, it will reconnect and pick up in the current live position, like you have suggested, without stopping. If it cannot reconnect after 3 times, it goes to the next playlist item. If the playlist is on repeat, it runs indefinitely. Brad Isbell brad at musatcha.com http://www.musatcha.com On Wed, Apr 26, 2017 at 1:58 PM, Jack Elliott wrote: > It's behaving as it is meant to: if a listen client gets too far behind, > Icecast2 server is kicking them off. > > error.log says, > > "INFO source/source.c Client 120 (xxx.xxx.xxx.xxx) has fallen too far > behind, removing" > > I don't see a setting in icecast.xml that sets the value for "too far > behind". I'm guessing it's related to . > > I wish Icecast could dump the buffer and bring the listen-client back up > to date instead of dumping the client. The reason being that when network > congestion causes Icecast to kick my listen-client off, the client > application just gives up. And this is a listen-client I'd like to have > running 24/7 so I can monitor the station's backroom server when we are > doing all-day music remotes. > > I haven't found a media/url player that attempts re-connect when kicked > off. At least under Linux. On Windows a player called AIMP3 works great: if > it is disconnected from the server, it tries to reconnect. Over and over > and over. I like that behavior. > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thatjackelliott at kpov.org Thu Apr 27 04:58:41 2017 From: thatjackelliott at kpov.org (Jack Elliott) Date: Wed, 26 Apr 2017 21:58:41 -0700 Subject: [Icecast] Server kicking clients off In-Reply-To: References: Message-ID: <7e8b2d4f-6a54-d9c0-2bbe-8971d6256d78@kpov.org> Thanks, Brad -- I first turned to VLC but my stream-client device is a Raspberry Pi 3, and there doesn't seem to be a build for the device. That said, I just stumbled across mpg123, a command-line mp3/stream player that has audio buffer and timeout setting which so far looks quite robust. For Icecast2 content, when Icecast kicks a client off for being "too far behind" -- what is "too far"? -- That Jack Elliott (541) 848 7021 KPOV 88.9 FM High Desert Community radio Producer, The Wednesday Point Host, The Sunday Classics On 04/26/2017 08:10 PM, Brad Isbell wrote: > Simply use VLC and put it on repeat. If a connection is lost during > playback, it will reconnect and pick up in the current live position, > like you have suggested, without stopping. If it cannot reconnect > after 3 times, it goes to the next playlist item. If the playlist is > on repeat, it runs indefinitely. > > Brad Isbell > brad at musatcha.com > http://www.musatcha.com > > On Wed, Apr 26, 2017 at 1:58 PM, Jack Elliott > > wrote: > > It's behaving as it is meant to: if a listen client gets too far > behind, Icecast2 server is kicking them off. > > error.log says, > > "INFO source/source.c Client 120 (xxx.xxx.xxx.xxx) has fallen too > far behind, removing" > > I don't see a setting in icecast.xml that sets the value for "too > far behind". I'm guessing it's related to . > > I wish Icecast could dump the buffer and bring the listen-client > back up to date instead of dumping the client. The reason being > that when network congestion causes Icecast to kick my > listen-client off, the client application just gives up. And this > is a listen-client I'd like to have running 24/7 so I can monitor > the station's backroom server when we are doing all-day music remotes. > > I haven't found a media/url player that attempts re-connect when > kicked off. At least under Linux. On Windows a player called AIMP3 > works great: if it is disconnected from the server, it tries to > reconnect. Over and over and over. I like that behavior. > > -- > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abitar.com at gmail.com Thu Apr 27 15:36:07 2017 From: abitar.com at gmail.com (David Saunders) Date: Thu, 27 Apr 2017 11:36:07 -0400 Subject: [Icecast] Server kicking clients off In-Reply-To: <7e8b2d4f-6a54-d9c0-2bbe-8971d6256d78@kpov.org> References: <7e8b2d4f-6a54-d9c0-2bbe-8971d6256d78@kpov.org> Message-ID: Hey, Something about streaming. Live streams are not live, they can be up to 15 to 20 sec off original encoding. This is to to overhead on both the server and client for encoding/decoding the stream, Any trans coding, and and buffering that has to be done on a "slow" connection. Unless the client decoder has some way to sync the stream, this delay will grow tell icecast server decides I have no more buffer t back into and drops them. This can be really pronounced if the connection jumps through a satellite. You can help this by maxing out the following settings: queue-size : This is the buffer you want to allow the client to fall behind. burst-size: This is how much data you want to fill send to the client when they connect to fill up the client buffers. You can also provide a lower quality stream(lower bandwidth) for those who have bad connections. What I do is if we get allot of slow listeners, I go though the log determined how many unique one are falling out of the queue. And tweak up the queue size or offer a lower quality connection to them when they connect again :) Since we from time to time have issues with connection spammers. (They connect to the server 1000/sec, and the slow listens sky rocket) I use a php traffic controller and black list on the icecast server to insure the best experience for our listeners. Just remember, setup the streams at the lowest possible encoding as you can. There are people who still are not on broadband connections around the world. David. On Thu, Apr 27, 2017 at 12:58 AM, Jack Elliott wrote: > Thanks, Brad -- I first turned to VLC but my stream-client device is a > Raspberry Pi 3, and there doesn't seem to be a build for the device. That > said, I just stumbled across mpg123, a command-line mp3/stream player that > has audio buffer and timeout setting which so far looks quite robust. > > For Icecast2 content, when Icecast kicks a client off for being "too far > behind" -- what is "too far"? > > -- > 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 04/26/2017 08:10 PM, Brad Isbell wrote: > > Simply use VLC and put it on repeat. If a connection is lost during > playback, it will reconnect and pick up in the current live position, like > you have suggested, without stopping. If it cannot reconnect after 3 > times, it goes to the next playlist item. If the playlist is on repeat, it > runs indefinitely. > > Brad Isbell > brad at musatcha.com > http://www.musatcha.com > > On Wed, Apr 26, 2017 at 1:58 PM, Jack Elliott > wrote: > >> It's behaving as it is meant to: if a listen client gets too far behind, >> Icecast2 server is kicking them off. >> >> error.log says, >> >> "INFO source/source.c Client 120 (xxx.xxx.xxx.xxx) has fallen too far >> behind, removing" >> >> I don't see a setting in icecast.xml that sets the value for "too far >> behind". I'm guessing it's related to . >> >> I wish Icecast could dump the buffer and bring the listen-client back up >> to date instead of dumping the client. The reason being that when network >> congestion causes Icecast to kick my listen-client off, the client >> application just gives up. And this is a listen-client I'd like to have >> running 24/7 so I can monitor the station's backroom server when we are >> doing all-day music remotes. >> >> I haven't found a media/url player that attempts re-connect when kicked >> off. At least under Linux. On Windows a player called AIMP3 works great: if >> it is disconnected from the server, it tries to reconnect. Over and over >> and over. I like that behavior. >> >> -- >> 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: From thatjackelliott at kpov.org Fri Apr 28 15:11:12 2017 From: thatjackelliott at kpov.org (Jack Elliott) Date: Fri, 28 Apr 2017 08:11:12 -0700 Subject: [Icecast] Server kicking clients off In-Reply-To: References: <7e8b2d4f-6a54-d9c0-2bbe-8971d6256d78@kpov.org> Message-ID: <65f885ef-eb74-5b74-df16-89a0c8ccb59f@kpov.org> "Live streams are not live, they can be up to 15 to 20 sec off original encoding." Something you become aware of very quickly when you're announcing into a mic and have to wait to hear your words! We do a bit of pre-show calibration with folks at the station to determine how long the delay ("latency" in digital-speak) is at the start of the remote broadcast, and start our remote announcing that number of seconds before the start of the show so they come out of the buffers at the right time. And at the end of the remote's broadcast day, we do the same as latency tends to build up over the period of the show. We often say, "and thank you for listening," a full 30 seconds before the scheduled end of the remote so that the studio programming can take over at the scheduled time. For our setup there are two listen-clients: we knuckleheads monitoring at the remote event, and a listen-client at the studio, which feeds the broadcast console and thence to our radio listeners. The listen client at the station won't fall too far behind because it's on the same LAN as the Icecast server. It's us knuckleheads out at the remote, checking in with the stream to assure that our stream is getting to the server, who can get kicked off due to falling too far behind. For music-grade stereo sound we encode to 192kbps mp3. Ogg might be better-sounding, but they use iTunes and/or Windows Media Player at the station to play the stream and mp3 is your lowest common denominator. They fear change at the studio. _Question_: can the icecast server be set up with two listen-client mountpoints? Both using the same source-client mountpoint, with one listen-client mountpoint for studio playback at the encoded bitrate, and a second listen-client mountpoint re-encoded to a lower bitrate for us knuckleheads to use at the remote end to monitor? That may add additional latency for the re-encoding but it might be more reliable. -- That Jack Elliott (541) 848 7021 KPOV 88.9 FM High Desert Community radio Producer, The Wednesday Point Host, The Sunday Classics On 04/27/2017 08:36 AM, David Saunders wrote: > Hey, > > Something about streaming. > Live streams are not live, they can be up to 15 to 20 sec off > original encoding. This is to to overhead on both the server and > client for encoding/decoding the stream, Any trans coding, and and > buffering that has to be done on a "slow" connection. Unless the > client decoder has some way to sync the stream, this delay will grow > tell icecast server decides I have no more buffer t back into and > drops them. This can be really pronounced if the connection jumps > through a satellite. > > You can help this by maxing out the following settings: > queue-size : This is the buffer you want to allow the client to > fall behind. > burst-size: This is how much data you want to fill send to the > client when they connect to fill up the client buffers. > > You can also provide a lower quality stream(lower bandwidth) for those > who have bad connections. > > What I do is if we get allot of slow listeners, I go though the log > determined how many unique one are falling out of the queue. And > tweak up the queue size or offer a lower quality connection to them > when they connect again :) Since we from time to time have issues > with connection spammers. (They connect to the server 1000/sec, and > the slow listens sky rocket) I use a php traffic controller and black > list on the icecast server to insure the best experience for our > listeners. > > Just remember, setup the streams at the lowest possible encoding as > you can. There are people who still are not on broadband connections > around the world. > > David. > > > > On Thu, Apr 27, 2017 at 12:58 AM, Jack Elliott > > wrote: > > Thanks, Brad -- I first turned to VLC but my stream-client device > is a Raspberry Pi 3, and there doesn't seem to be a build for the > device. That said, I just stumbled across mpg123, a command-line > mp3/stream player that has audio buffer and timeout setting which > so far looks quite robust. > > For Icecast2 content, when Icecast kicks a client off for being > "too far behind" -- what is "too far"? > > -- > That Jack Elliott > (541) 848 7021 > KPOV 88.9 FM High Desert Community radio > Producer, The Wednesday Point > Host, The Sunday Classics > > On 04/26/2017 08:10 PM, Brad Isbell wrote: >> Simply use VLC and put it on repeat. If a connection is lost >> during playback, it will reconnect and pick up in the current >> live position, like you have suggested, without stopping. If it >> cannot reconnect after 3 times, it goes to the next playlist >> item. If the playlist is on repeat, it runs indefinitely. >> >> Brad Isbell >> brad at musatcha.com >> http://www.musatcha.com >> >> On Wed, Apr 26, 2017 at 1:58 PM, Jack Elliott >> > wrote: >> >> It's behaving as it is meant to: if a listen client gets too >> far behind, Icecast2 server is kicking them off. >> >> error.log says, >> >> "INFO source/source.c Client 120 (xxx.xxx.xxx.xxx) has fallen >> too far behind, removing" >> >> I don't see a setting in icecast.xml that sets the value for >> "too far behind". I'm guessing it's related to . >> >> I wish Icecast could dump the buffer and bring the >> listen-client back up to date instead of dumping the client. >> The reason being that when network congestion causes Icecast >> to kick my listen-client off, the client application just >> gives up. And this is a listen-client I'd like to have >> running 24/7 so I can monitor the station's backroom server >> when we are doing all-day music remotes. >> >> I haven't found a media/url player that attempts re-connect >> when kicked off. At least under Linux. On Windows a player >> called AIMP3 works great: if it is disconnected from the >> server, it tries to reconnect. Over and over and over. I like >> that behavior. >> >> -- >> 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: From abitar.com at gmail.com Fri Apr 28 21:49:00 2017 From: abitar.com at gmail.com (David Saunders) Date: Fri, 28 Apr 2017 17:49:00 -0400 Subject: [Icecast] Server kicking clients off In-Reply-To: <65f885ef-eb74-5b74-df16-89a0c8ccb59f@kpov.org> References: <7e8b2d4f-6a54-d9c0-2bbe-8971d6256d78@kpov.org> <65f885ef-eb74-5b74-df16-89a0c8ccb59f@kpov.org> Message-ID: hey, I cast itself can not re encode a stream, you would have to use something like dark ice or vlc to set up as a listener and then source the new encoded stream on another mount point. The external program will encode the stream in what ever format is needed. Mp3 are private and can run into use laws and Ogg is ope n to use. I not seen any body taken town because of it yet. I would worry more about the internet latency then worry about much latency is added with re encoding. Offering slower encoding should help out those who don't have faster internet. DAvid. On Fri, Apr 28, 2017 at 11:11 AM, Jack Elliott wrote: > "Live streams are not live, they can be up to 15 to 20 sec off original > encoding." > > Something you become aware of very quickly when you're announcing into a > mic and have to wait to hear your words! > > We do a bit of pre-show calibration with folks at the station to determine > how long the delay ("latency" in digital-speak) is at the start of the > remote broadcast, and start our remote announcing that number of seconds > before the start of the show so they come out of the buffers at the right > time. And at the end of the remote's broadcast day, we do the same as > latency tends to build up over the period of the show. We often say, "and > thank you for listening," a full 30 seconds before the scheduled end of the > remote so that the studio programming can take over at the scheduled time. > > For our setup there are two listen-clients: we knuckleheads monitoring at > the remote event, and a listen-client at the studio, which feeds the > broadcast console and thence to our radio listeners. The listen client at > the station won't fall too far behind because it's on the same LAN as the > Icecast server. It's us knuckleheads out at the remote, checking in with > the stream to assure that our stream is getting to the server, who can get > kicked off due to falling too far behind. > > For music-grade stereo sound we encode to 192kbps mp3. Ogg might be > better-sounding, but they use iTunes and/or Windows Media Player at the > station to play the stream and mp3 is your lowest common denominator. They > fear change at the studio. > > *Question*: can the icecast server be set up with two listen-client > mountpoints? Both using the same source-client mountpoint, with one > listen-client mountpoint for studio playback at the encoded bitrate, and a > second listen-client mountpoint re-encoded to a lower bitrate for us > knuckleheads to use at the remote end to monitor? That may add additional > latency for the re-encoding but it might be more reliable. > > -- > 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 04/27/2017 08:36 AM, David Saunders wrote: > > Hey, > > Something about streaming. > > Live streams are not live, they can be up to 15 to 20 sec off > original encoding. This is to to overhead on both the server and client > for encoding/decoding the stream, Any trans coding, and and buffering that > has to be done on a "slow" connection. Unless the client decoder has some > way to sync the stream, this delay will grow tell icecast server decides I > have no more buffer t back into and drops them. This can be really > pronounced if the connection jumps through a satellite. > > You can help this by maxing out the following settings: > queue-size : This is the buffer you want to allow the client to fall > behind. > burst-size: This is how much data you want to fill send to the > client when they connect to fill up the client buffers. > > You can also provide a lower quality stream(lower bandwidth) for those who > have bad connections. > > What I do is if we get allot of slow listeners, I go though the log > determined how many unique one are falling out of the queue. And tweak up > the queue size or offer a lower quality connection to them when they > connect again :) Since we from time to time have issues with connection > spammers. (They connect to the server 1000/sec, and the slow listens sky > rocket) I use a php traffic controller and black list on the icecast server > to insure the best experience for our listeners. > > Just remember, setup the streams at the lowest possible encoding as you > can. There are people who still are not on broadband connections around > the world. > > David. > > > > On Thu, Apr 27, 2017 at 12:58 AM, Jack Elliott > wrote: > >> Thanks, Brad -- I first turned to VLC but my stream-client device is a >> Raspberry Pi 3, and there doesn't seem to be a build for the device. That >> said, I just stumbled across mpg123, a command-line mp3/stream player that >> has audio buffer and timeout setting which so far looks quite robust. >> >> For Icecast2 content, when Icecast kicks a client off for being "too far >> behind" -- what is "too far"? >> >> -- >> 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 04/26/2017 08:10 PM, Brad Isbell wrote: >> >> Simply use VLC and put it on repeat. If a connection is lost during >> playback, it will reconnect and pick up in the current live position, like >> you have suggested, without stopping. If it cannot reconnect after 3 >> times, it goes to the next playlist item. If the playlist is on repeat, it >> runs indefinitely. >> >> Brad Isbell >> brad at musatcha.com >> http://www.musatcha.com >> >> On Wed, Apr 26, 2017 at 1:58 PM, Jack Elliott >> wrote: >> >>> It's behaving as it is meant to: if a listen client gets too far behind, >>> Icecast2 server is kicking them off. >>> >>> error.log says, >>> >>> "INFO source/source.c Client 120 (xxx.xxx.xxx.xxx) has fallen too far >>> behind, removing" >>> >>> I don't see a setting in icecast.xml that sets the value for "too far >>> behind". I'm guessing it's related to . >>> >>> I wish Icecast could dump the buffer and bring the listen-client back up >>> to date instead of dumping the client. The reason being that when network >>> congestion causes Icecast to kick my listen-client off, the client >>> application just gives up. And this is a listen-client I'd like to have >>> running 24/7 so I can monitor the station's backroom server when we are >>> doing all-day music remotes. >>> >>> I haven't found a media/url player that attempts re-connect when kicked >>> off. At least under Linux. On Windows a player called AIMP3 works great: if >>> it is disconnected from the server, it tries to reconnect. Over and over >>> and over. I like that behavior. >>> >>> -- >>> 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 >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thatjackelliott at kpov.org Sat Apr 29 04:53:12 2017 From: thatjackelliott at kpov.org (Jack Elliott) Date: Fri, 28 Apr 2017 21:53:12 -0700 Subject: [Icecast] Server not moving clients to fallback Message-ID: Hi, thanks in advance for any help that can be provided for this head-scratcher. I'm configuring a new server and can't get it to move listen clients to the fallback file when the source client disconnects. I probably have a misconfiguration in icecast.xml. Here is the section: /stream.mp3 65536 /fallbacks/Generic_Festival_fallback_192kHz.mp3 1 1 1 Seems okay. Here is the section: /usr/share/icecast2 /var/log/icecast2 /usr/share/icecast2/web /usr/share/icecast2/admin and 1 is /usr/share/icecast2/web and the fallback file is in "fallbacks" under it: pi at Pi:/usr/share/icecast2/web/fallbacks $ ls 400Hz_0dBFS_sine_15m.mp3 Generic_Festival_fallback_128kHz.mp3 fallback_400hz_minus_20dB.mp3 Generic_Festival_fallback_192kHz.mp3 Here is icecast's error.log when it starts up: [2017-04-28 21:34:07] INFO main/main Icecast 2.4.0 server started [2017-04-28 21:34:07] INFO connection/get_ssl_certificate No SSL capability [2017-04-28 21:34:07] INFO yp/yp_update_thread YP update thread started [2017-04-28 21:34:07] INFO source/source_fallback_file mountpoint /fallbacks/Generic_Festival_fallback_192kHz.mp3 is reserved [2017-04-28 21:34:07] WARN format/format_get_type Unsupported or legacy stream type: "audio/mpeg". Falling back to generic minimal handler for best effort. [2017-04-28 21:34:07] INFO source/source_main listener count on /fallbacks/Generic_Festival_fallback_192kHz.mp3 now 0 So server has found the fallback. No clients connected. Okay, start a stream pointed to /stream and the log adds: [2017-04-28 21:40:36] INFO connection/_handle_source_request Source logging in at mountpoint "/stream" [2017-04-28 21:40:36] WARN format/format_get_type Unsupported or legacy stream type: "audio/mpeg". Falling back to generic minimal handler for best effort. [2017-04-28 21:40:36] INFO admin/admin_handle_request Received admin command metadata on mount "/stream" [2017-04-28 21:40:36] INFO admin/command_metadata Metadata on mountpoint /stream changed to "asdfsdf" [2017-04-28 21:40:36] INFO source/source_main listener count on /stream now 0 Connect a listen client: [2017-04-28 21:41:40] INFO source/source_main listener count on /stream now 1 The listen-client is receiving the stream. Now, if I kill the source mount client: [2017-04-28 21:42:48] INFO source/get_next_buffer End of Stream /stream [2017-04-28 21:42:48] INFO source/source_shutdown Source "/stream" exiting [2017-04-28 21:42:48] INFO source/source_clear_source 1 active listeners on /stream released and the listen-client exits. There seems to be no attempt here to move the listen-client to the fallback mount ("/fallbacks/Generic_Festival_fallback_192kHz.mp3"). If I try to connect a listen-client when the /source client is not running, it doesn't find a mountpoint, server is not connecting it up. I get the same behavior with two different types of listen-clients, so I reckon I've got something not quite right in the config file, but error.log isn't revealing it to me. It baffles science. -- That Jack Elliott (541) 848 7021 KPOV 88.9 FM High Desert Community radio Producer, The Wednesday Point Host, The Sunday Classics