From marek at eclipse-streaming.co.za Fri Feb 2 10:04:33 2024 From: marek at eclipse-streaming.co.za (Marek Dziembowski) Date: Fri, 2 Feb 2024 10:04:33 +0000 Subject: [Icecast] Burst and queue-size vs slow_listeners tally Message-ID: Greetings ice-casters! I?m hoping to get some clarity and guidance on understanding the relation between queue-size and burst-size settings, and how this affects the slow_listener count shown on the admin pages. We are having constant issues with listeners eventually being disconnected at varying timespans, and I?ve tried adjusting burst-size and queue-size to find the right balance for avoiding long duration disconnects, but have had no joy yet. What exactly does the slow_listener count in relation to queue -size indicate? I?ve seen the slow_listeners number grow well beyond the number of connected listeners: Right now I am seeing: listeners 508 queue_size 2191778 slow_listeners 1501 How do I use this data to find the best queue-size and burst-size settings to keep listeners connected without dropout? Many thanks, Marek [cid:image001.jpg at 01DA55CE.0DD30C90] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 180354 bytes Desc: image001.jpg URL: From phschafft at de.loewenfelsen.net Fri Feb 2 10:46:53 2024 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Fri, 02 Feb 2024 10:46:53 +0000 Subject: [Icecast] Burst and queue-size vs slow_listeners tally In-Reply-To: References: Message-ID: <3f8410aa8729b590d9d019baa97124ab9e437b7a.camel@de.loewenfelsen.net> Good morning, On Fri, 2024-02-02 at 10:04 +0000, Marek Dziembowski wrote: > Greetings ice-casters! > ? > I?m hoping to get some clarity and guidance on understanding the > relation between queue-size and burst-size settings, and how this > affects the slow_listener count shown on the admin pages. it's not that complicated, so let's dig in a little: Icecast has a queue for the data. As soon as a source pushes new data that is added to this queue and if the queue then overshoot the queue size it's tail is cut to fit again. So the queue-size just gives the size of that data queue. Once a listener is connected they "swim" in this queue. Ideally they are right at the head of it getting the data as it comes in. However as clients have a internal buffer placing them right at the head of the queue would mean that they would first take take to fill their buffer. the burst size is how far behind the head of the queue we put them. This means this is the amount of data that is instantly available to them to pre-fill their buffer. What does that mean: * The burst size is always smaller or equal to the queue size as it is just part of it. * The burst size should match the listener's pre-buffer setting. It doesn't have any effects on connection quality or anything else. Practical considerations: * It is safe for the burst size to be too small (even 0 is valid). It would just increase the listeners pre-buffer time. * If the value is too big you over-fill the clients buffer to the point it will add extra latency (because the listener first needs to play out some of it). * Listener clients don't tell Icecast what they want. So this value is always a guess. * I would suggest to have it set to a few seconds worth at your average bitrate. The current default is 64kByte which is about 4.7s on 112kBit/s. If your bitrate is very different just scale it accordingly. * Lower is always "safe" so better go with a too low than with a too big value. * It is totally fine to play with this and see how long it takes for a client to start playing. But that is the only goal here. Not connected to the rest of your e-mail. (So an easy one!) > We are having constant issues with listeners eventually being > disconnected at varying timespans, and I?ve tried adjusting burst- > size and queue-size to find the right balance for avoiding long > duration disconnects, but have had no joy yet. Here the queue-size is important. As said above the listener "swims" in the queue. It is placed there and tries to keep up with the flow (from head to tail). The queue allows the listener to swim a bit faster or a bit slower as long as on average keeps up with the flow. This compensates for things like network jitters and player scheduling. A bigger queue size means that a listener is less likely to fall behind and hit the tail end. However in reality too high of a value here just means that you hide the cases of clients that actually died. So similar as above: consider how far a client may fall behind "live" (our head) and then make a number up. for example if we use a burst size of 4 seconds the queue might be 8 or 12 seconds long. But I wouldn't go with much more as a listener that can for example not read from Icecast in 12 seconds likely will not sustain a stable stream even if you give it more time. > What exactly does the slow_listener count in relation to queue -size > indicate? I?ve seen the slow_listeners number grow well beyond the > number of connected listeners: When a listener hist the tail it is considered slow and removed. The infamous "Client [...] has fallen too far behind, removing" error. This just means that they could not keep up. So the value you see is the counter of how often that happened. It is the sum and expected to only grow. The speed of it growing is what is interesting not the value. And even that value needs to be put in context: e.g. when you have many mobile listeners the value is expected to grow faster. When you have listeners all in the same building as your Icecast server you should hardly see the number grow. So if at all you compare that number directly to something compare it to your total amount of listeners, not the current value. :) ? > Right now I am seeing: > listeners > 508 > queue_size > 2191778 > slow_listeners > 1501 If you're having 508 listeners constantly and your server is running for some time 1501 slow listeners wouldn't be too much of an alarm to me. :) > How do I use this data to find the best queue-size and burst-size > settings to keep listeners connected without dropout? I hope my hints help you a bit. :) With best regards, PS: I just realised that a fish and swim example is most appropriate for a Xiph.Org Foundation project. -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephone:???????????+49.3535 490 17 92 Website:?????????????https://www.loewenfelsen.net/ Follow us:???????????https://www.linkedin.com/company/loewenfelsen/ Gesch?ftsf?hrer/CEO: Philipp Schafft L?wenfelsen UG (haftungsbeschr?nkt)?????Registration number: Bickinger Stra?e 21?????????????????????HRB 12308 CB 04916 Herzberg (Elster)?????????????????VATIN/USt-ID: Germany?????????????????????????????????DE305133015 From dave at dashs.denver.co.us Mon Feb 5 23:33:35 2024 From: dave at dashs.denver.co.us (Dave Serls) Date: Mon, 5 Feb 2024 16:33:35 -0700 Subject: [Icecast] Upgrade problem? Message-ID: <20240205163335.0fb3b4b8@beppo.dashs.denver.co.us> I'm using the Debian stable version 3.4.4-4 with the original ices. Yes, that's correct. Up to 3.4.4-1 all has been well. Some type of protocol error is producing: EROR connection/_handle_connection HTTP request parsing failed EROR admin/admin_handle_request Error parsing command string or unrecognised command: !POKE on every change of tune. Needless to say ices has not changed in many a moon. What other icecast.xml change might produce this? -- ************************************************************************ * Dave Serls Littleton, CO, USA * * dashs.denver.co.us http://www.dashs.com * ************************************************************************ From dave at dashs.denver.co.us Tue Feb 6 19:46:57 2024 From: dave at dashs.denver.co.us (Dave Serls) Date: Tue, 6 Feb 2024 12:46:57 -0700 Subject: [Icecast] Upgrade problem? In-Reply-To: <20240205163335.0fb3b4b8@beppo.dashs.denver.co.us> References: <20240205163335.0fb3b4b8@beppo.dashs.denver.co.us> Message-ID: <20240206124657.09893458@beppo.dashs.denver.co.us> On Mon, 5 Feb 2024 16:33:35 -0700 Dave Serls wrote: > I'm using the Debian stable version 3.4.4-4 with the original ices. > Yes, that's correct. Up to 3.4.4-1 all has been well. > Some type of protocol error is producing: > EROR connection/_handle_connection HTTP request parsing failed > EROR admin/admin_handle_request Error parsing command string or > unrecognised command: !POKE > > on every change of tune. > Needless to say ices has not changed in many a moon. > What other icecast.xml change might produce this? Looks like it comes out of libshout 3.20 . Is this some kind of survey? -- ************************************************************************ * Dave Serls Littleton, CO, USA * * dashs.denver.co.us http://www.dashs.com * ************************************************************************ From googe at googe.tv Fri Feb 9 04:57:36 2024 From: googe at googe.tv (Googe) Date: Thu, 8 Feb 2024 20:57:36 -0800 Subject: [Icecast] compiling icecast on ARM Mac errors Message-ID: I moved to an ARM based Mac and installed the ARM Homebrew... When trying to compile icecast using: PKG_CONFIG_PATH=/opt/homebrew/Cellar/openssl at 3/3.2.1/lib/pkgconfig ./configure I get an error before it finishes : checking for libogg... not found checking for libvorbis... configure: error: must have Ogg Vorbis v1.0 or above installed Even though the latest libogg and libvorbis are installed! I tried with openssl at 3 and older version openssl at 3.00 Any idea what I can do to fix this? Or is there a way to ignore ogg in the .configure -------------- next part -------------- An HTML attachment was scrubbed... URL: From epirat07 at gmail.com Fri Feb 9 09:26:55 2024 From: epirat07 at gmail.com (epirat07 at gmail.com) Date: Fri, 09 Feb 2024 10:26:55 +0100 Subject: [Icecast] compiling icecast on ARM Mac errors In-Reply-To: References: Message-ID: On 9 Feb 2024, at 5:57, Googe wrote: > I moved to an ARM based Mac and installed the ARM Homebrew... > > When trying to compile icecast using: > > PKG_CONFIG_PATH=/opt/homebrew/Cellar/openssl at 3/3.2.1/lib/pkgconfig ./configure > Make sure your pkg-config can find ogg and vorbis. > I get an error before it finishes : > > checking for libogg... not found > checking for libvorbis... configure: error: must have Ogg Vorbis v1.0 or above installed > > Even though the latest libogg and libvorbis are installed! > > I tried with openssl at 3 and older version openssl at 3.00 > > Any idea what I can do to fix this? > > Or is there a way to ignore ogg in the .configure > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From googe at googe.tv Fri Feb 9 20:57:42 2024 From: googe at googe.tv (Googe) Date: Fri, 9 Feb 2024 12:57:42 -0800 Subject: [Icecast] compiling icecast on ARM Mac errors In-Reply-To: References: Message-ID: <45caed07-21ab-48ae-bc32-e13894549b04@googe.tv> Yes, pkg-config has the path, still not working... thanks On 2/9/24 1:26 AM, epirat07 at gmail.com wrote: > On 9 Feb 2024, at 5:57, Googe wrote: > >> I moved to an ARM based Mac and installed the ARM Homebrew... >> >> When trying to compile icecast using: >> >> PKG_CONFIG_PATH=/opt/homebrew/Cellar/openssl at 3/3.2.1/lib/pkgconfig ./configure >> > Make sure your pkg-config can find ogg and vorbis. > >> I get an error before it finishes : >> >> checking for libogg... not found >> checking for libvorbis... configure: error: must have Ogg Vorbis v1.0 or above installed >> >> Even though the latest libogg and libvorbis are installed! >> >> I tried with openssl at 3 and older versionopenssl at 3.00 >> >> Any idea what I can do to fix this? >> >> Or is there a way to ignore ogg in the .configure >> _______________________________________________ >> 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 epirat07 at gmail.com Sat Feb 10 01:51:46 2024 From: epirat07 at gmail.com (epirat07 at gmail.com) Date: Sat, 10 Feb 2024 02:51:46 +0100 Subject: [Icecast] compiling icecast on ARM Mac errors In-Reply-To: <45caed07-21ab-48ae-bc32-e13894549b04@googe.tv> References: <45caed07-21ab-48ae-bc32-e13894549b04@googe.tv> Message-ID: On 9 Feb 2024, at 21:57, Googe wrote: > Yes, pkg-config has the path, still not working... > Can you share your config.log please? > thanks > > On 2/9/24 1:26 AM, epirat07 at gmail.com wrote: >> On 9 Feb 2024, at 5:57, Googe wrote: >> >>> I moved to an ARM based Mac and installed the ARM Homebrew... >>> >>> When trying to compile icecast using: >>> >>> PKG_CONFIG_PATH=/opt/homebrew/Cellar/openssl at 3/3.2.1/lib/pkgconfig ./configure >>> >> Make sure your pkg-config can find ogg and vorbis. >> >>> I get an error before it finishes : >>> >>> checking for libogg... not found >>> checking for libvorbis... configure: error: must have Ogg Vorbis v1.0 or above installed >>> >>> Even though the latest libogg and libvorbis are installed! >>> >>> I tried with openssl at 3 and older versionopenssl at 3.00 >>> >>> Any idea what I can do to fix this? >>> >>> Or is there a way to ignore ogg in the .configure >>> _______________________________________________ >>> 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 From googe at googe.tv Sat Feb 10 01:49:53 2024 From: googe at googe.tv (Googe) Date: Fri, 9 Feb 2024 17:49:53 -0800 Subject: [Icecast] compiling icecast on ARM Mac errors In-Reply-To: <45caed07-21ab-48ae-bc32-e13894549b04@googe.tv> References: <45caed07-21ab-48ae-bc32-e13894549b04@googe.tv> Message-ID: I finally got it compiling (with openssl btw) by doing this. I put the following in my .bash_profile export OGG_PREFIX=/opt/homebrew/opt/libogg export VORBIS_PREFIX=/opt/homebrew/opt/libvorbis then I checked with: env | grep OGG_PREFIX env | grep VORBIS_PREFIX Then I just used: ./configure and it worked, no more can't find ogg or vorbis errors. ?then ran:? make I believe this all had to do with migrating from Mac Intel Homebrew to Mac ARM Homebrew. On 2/9/24 12:57 PM, Googe wrote: > Yes, pkg-config has the path, still not working... > > thanks > > On 2/9/24 1:26 AM, epirat07 at gmail.com wrote: >> On 9 Feb 2024, at 5:57, Googe wrote: >> >>> I moved to an ARM based Mac and installed the ARM Homebrew... >>> >>> When trying to compile icecast using: >>> >>> PKG_CONFIG_PATH=/opt/homebrew/Cellar/openssl at 3/3.2.1/lib/pkgconfig ./configure >>> >> Make sure your pkg-config can find ogg and vorbis. >> >>> I get an error before it finishes : >>> >>> checking for libogg... not found >>> checking for libvorbis... configure: error: must have Ogg Vorbis v1.0 or above installed >>> >>> Even though the latest libogg and libvorbis are installed! >>> >>> I tried with openssl at 3 and older versionopenssl at 3.00 >>> >>> Any idea what I can do to fix this? >>> >>> Or is there a way to ignore ogg in the .configure >>> _______________________________________________ >>> 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 phschafft at de.loewenfelsen.net Mon Feb 12 11:35:30 2024 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Mon, 12 Feb 2024 11:35:30 +0000 Subject: [Icecast] Upgrade problem? In-Reply-To: <20240205163335.0fb3b4b8@beppo.dashs.denver.co.us> References: <20240205163335.0fb3b4b8@beppo.dashs.denver.co.us> Message-ID: <83f090c830269cf6372a78d975b838e6cdbd8c54.camel@de.loewenfelsen.net> Good morning, as nobody else jumped in, let me try to figure it out. :) On Mon, 2024-02-05 at 16:33 -0700, Dave Serls wrote: > > ?I'm using the Debian stable version 3.4.4-4 with the original ices. > ?Yes, that's correct. Up to 3.4.4-1? all has been well. > ?Some type of protocol error is producing: > ?? EROR connection/_handle_connection HTTP request parsing failed? > ?? EROR admin/admin_handle_request Error parsing command string or > ?? unrecognised command: !POKE POKE-requests are part of libshout performing detection of sever features and bugs. This is for compatibility with both very old Icecast servers or when for example talking to some other software that never implemented everything. > ?? on every change of tune. I'm not sure about this part. My guess is that you talk to ICY metadata updates in the legacy format support. From having a quick look at the code, it might be true that libshout does a POKE here for every update. > ?? Needless to say ices has not changed in many a moon. > ?? What other icecast.xml change might produce this? This is something related to libshout's implementation. So an update on that might have changed things. Also keep in mind that this is purely source client side, so this doesn't depend on the Icecast or it's config at all. So generally speaking this is totally fine to happen. And not a problem at all. No actions required. If in fact it does this for every update in the legacy code path that is a bit unfortunate. Maybe we can have a look at that and see if we can cache the result. But beside an error.log entry there is no harm to it. Hope that helped! :) With best regards, -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephone:???????????+49.3535 490 17 92 Website:?????????????https://www.loewenfelsen.net/ Follow us:???????????https://www.linkedin.com/company/loewenfelsen/ Gesch?ftsf?hrer/CEO: Philipp Schafft L?wenfelsen UG (haftungsbeschr?nkt)?????Registration number: Bickinger Stra?e 21?????????????????????HRB 12308 CB 04916 Herzberg (Elster)?????????????????VATIN/USt-ID: Germany?????????????????????????????????DE305133015 From dave at dashs.denver.co.us Mon Feb 12 13:09:24 2024 From: dave at dashs.denver.co.us (Dave Serls) Date: Mon, 12 Feb 2024 06:09:24 -0700 Subject: [Icecast] Upgrade problem? In-Reply-To: <83f090c830269cf6372a78d975b838e6cdbd8c54.camel@de.loewenfelsen.net> References: <20240205163335.0fb3b4b8@beppo.dashs.denver.co.us> <83f090c830269cf6372a78d975b838e6cdbd8c54.camel@de.loewenfelsen.net> Message-ID: <20240212060924.7ae8f513@beppo.dashs.denver.co.us> On Mon, 12 Feb 2024 11:35:30 +0000 Philipp Schafft wrote: > Good morning, > > as nobody else jumped in, let me try to figure it out. :) > > On Mon, 2024-02-05 at 16:33 -0700, Dave Serls wrote: > > > > ?I'm using the Debian stable version 3.4.4-4 with the original ices. > > ?Yes, that's correct. Up to 3.4.4-1? all has been well. > > ?Some type of protocol error is producing: > > ?? EROR connection/_handle_connection HTTP request parsing failed? > > ?? EROR admin/admin_handle_request Error parsing command string or > > ?? unrecognised command: !POKE > > POKE-requests are part of libshout performing detection of sever > features and bugs. This is for compatibility with both very old > Icecast servers or when for example talking to some other software > that never implemented everything. > > > > ?? on every change of tune. > > I'm not sure about this part. My guess is that you talk to ICY > metadata updates in the legacy format support. From having a quick > look at the code, it might be true that libshout does a POKE here for > every update. > > > > ?? Needless to say ices has not changed in many a moon. > > ?? What other icecast.xml change might produce this? > > This is something related to libshout's implementation. So an update > on that might have changed things. Also keep in mind that this is > purely source client side, so this doesn't depend on the Icecast or > it's config at all. > > So generally speaking this is totally fine to happen. And not a > problem at all. No actions required. > If in fact it does this for every update in the legacy code path that > is a bit unfortunate. Maybe we can have a look at that and see if we > can cache the result. But beside an error.log entry there is no harm > to it. > > Hope that helped! :) > > > With best regards, > Thanks much, Philipp. When I saw that libshout was the origin, I realized that Icecast was not involved, but knew that you could sort it out. This use-case is a hobbyist imbedded audio server on old i386 hardware. I have the luxury of not needing to upgrade. Thanks again. -- ************************************************************************ * Dave Serls Littleton, CO, USA * * dashs.denver.co.us http://www.dashs.com * ************************************************************************ From ak18 at 5x9.de Mon Feb 12 15:30:44 2024 From: ak18 at 5x9.de (ak18 at 5x9.de) Date: Mon, 12 Feb 2024 16:30:44 +0100 Subject: [Icecast] Multiple SSL certificates In-Reply-To: <20240212060924.7ae8f513@beppo.dashs.denver.co.us> References: <20240205163335.0fb3b4b8@beppo.dashs.denver.co.us> <83f090c830269cf6372a78d975b838e6cdbd8c54.camel@de.loewenfelsen.net> <20240212060924.7ae8f513@beppo.dashs.denver.co.us> Message-ID: DE: Kann man bei Icecast mehrere SSL-Zertifikate konfigurieren um mehrere Domainnamen per https zu verwenden und wenn ja, wie? EN: Is it possible to configure multiple SSL certificates with Icecast to use multiple domain names via https and if so, how? From uktony at radiocompany.net Mon Feb 12 18:19:52 2024 From: uktony at radiocompany.net (uktony) Date: Tue, 13 Feb 2024 02:19:52 +0800 Subject: [Icecast] Multiple SSL certificates In-Reply-To: Message-ID: <1707761998541.41d219c77d53c214@radiocompany.net> Yes, great question.Can you get icecast, one instalation, running two or more stations, respond with more than one SSL cert?Ice.domain1.comIce.domain2.netDepends how you address the server?TonySent from my Galaxy -------- Original message --------From: ak18 at 5x9.de Date: 13/02/2024 00:32 (GMT+08:00) To: icecast at xiph.org Subject: [Icecast] Multiple SSL certificates DE:Kann man bei Icecast mehrere SSL-Zertifikate konfigurieren um mehrere Domainnamen per https zu verwenden und wenn ja, wie?EN:Is it possible to configure multiple SSL certificates with Icecast to use multiple domain names via https and if so, how?_______________________________________________Icecast mailing listIcecast at xiph.orghttp://lists.xiph.org/mailman/listinfo/icecast -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact+dev at gilouweb.com Mon Feb 12 19:08:05 2024 From: contact+dev at gilouweb.com (Gilou) Date: Mon, 12 Feb 2024 20:08:05 +0100 Subject: [Icecast] Multiple SSL certificates In-Reply-To: References: <20240205163335.0fb3b4b8@beppo.dashs.denver.co.us> <83f090c830269cf6372a78d975b838e6cdbd8c54.camel@de.loewenfelsen.net> <20240212060924.7ae8f513@beppo.dashs.denver.co.us> Message-ID: Le 12/02/2024 ? 16:30, ak18 at 5x9.de a ?crit?: > DE: > > Kann man bei Icecast mehrere SSL-Zertifikate konfigurieren um mehrere > Domainnamen per https zu verwenden und wenn ja, wie? > > EN: > > Is it possible to configure multiple SSL certificates with Icecast to > use multiple domain names via https and if so, how? > Hi, Since I'm almost sure we don't do SNI or hostname validation server side, you'll need a certificate that has the required domains in the CommonName / SubjectAltName parts of the certificate. Now? will clients behave with that, maybe that would require testing. Cheers, Gilou From yahav.shasha at gmail.com Mon Feb 12 19:17:30 2024 From: yahav.shasha at gmail.com (Yahav Shasha) Date: Mon, 12 Feb 2024 21:17:30 +0200 Subject: [Icecast] Multiple SSL certificates In-Reply-To: <1707761998541.41d219c77d53c214@radiocompany.net> References: <1707761998541.41d219c77d53c214@radiocompany.net> Message-ID: Easiest and most efficient way I can think of would be to purchase a multi-domain certificate. An alternative would be to reverse proxy Icecast with nginx or any other server and set the certificates each to its own vhost. ?????? ??? ??, 12 ????? 2024 ?-20:38 ??? uktony : > Yes, great question. > > Can you get icecast, one instalation, running two or more stations, > respond with more than one SSL cert? > > Ice.domain1.com > Ice.domain2.net > > Depends how you address the server? > > Tony > > > > Sent from my Galaxy > > > -------- Original message -------- > From: ak18 at 5x9.de > Date: 13/02/2024 00:32 (GMT+08:00) > To: icecast at xiph.org > Subject: [Icecast] Multiple SSL certificates > > DE: > > Kann man bei Icecast mehrere SSL-Zertifikate konfigurieren um mehrere > Domainnamen per https zu verwenden und wenn ja, wie? > > EN: > > Is it possible to configure multiple SSL certificates with Icecast to > use multiple domain names via https and if so, how? > > > _______________________________________________ > 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 marek at eclipse-streaming.co.za Tue Feb 13 07:18:04 2024 From: marek at eclipse-streaming.co.za (Marek Dziembowski) Date: Tue, 13 Feb 2024 07:18:04 +0000 Subject: [Icecast] Burst and queue-size vs slow_listeners tally In-Reply-To: <3f8410aa8729b590d9d019baa97124ab9e437b7a.camel@de.loewenfelsen.net> References: <3f8410aa8729b590d9d019baa97124ab9e437b7a.camel@de.loewenfelsen.net> Message-ID: Wow thank you so much for the great explanation! ? -----Original Message----- From: Icecast On Behalf Of Philipp Schafft Sent: Friday, February 2, 2024 12:47 PM To: Icecast streaming server user discussions Subject: Re: [Icecast] Burst and queue-size vs slow_listeners tally Good morning, On Fri, 2024-02-02 at 10:04 +0000, Marek Dziembowski wrote: > Greetings ice-casters! > ? > I?m hoping to get some clarity and guidance on understanding the > relation between queue-size and burst-size settings, and how this > affects the slow_listener count shown on the admin pages. it's not that complicated, so let's dig in a little: Icecast has a queue for the data. As soon as a source pushes new data that is added to this queue and if the queue then overshoot the queue size it's tail is cut to fit again. So the queue-size just gives the size of that data queue. Once a listener is connected they "swim" in this queue. Ideally they are right at the head of it getting the data as it comes in. However as clients have a internal buffer placing them right at the head of the queue would mean that they would first take take to fill their buffer. the burst size is how far behind the head of the queue we put them. This means this is the amount of data that is instantly available to them to pre-fill their buffer. What does that mean: * The burst size is always smaller or equal to the queue size as it is just part of it. * The burst size should match the listener's pre-buffer setting. It doesn't have any effects on connection quality or anything else. Practical considerations: * It is safe for the burst size to be too small (even 0 is valid). It would just increase the listeners pre-buffer time. * If the value is too big you over-fill the clients buffer to the point it will add extra latency (because the listener first needs to play out some of it). * Listener clients don't tell Icecast what they want. So this value is always a guess. * I would suggest to have it set to a few seconds worth at your average bitrate. The current default is 64kByte which is about 4.7s on 112kBit/s. If your bitrate is very different just scale it accordingly. * Lower is always "safe" so better go with a too low than with a too big value. * It is totally fine to play with this and see how long it takes for a client to start playing. But that is the only goal here. Not connected to the rest of your e-mail. (So an easy one!) > We are having constant issues with listeners eventually being > disconnected at varying timespans, and I?ve tried adjusting burst- > size and queue-size to find the right balance for avoiding long > duration disconnects, but have had no joy yet. Here the queue-size is important. As said above the listener "swims" in the queue. It is placed there and tries to keep up with the flow (from head to tail). The queue allows the listener to swim a bit faster or a bit slower as long as on average keeps up with the flow. This compensates for things like network jitters and player scheduling. A bigger queue size means that a listener is less likely to fall behind and hit the tail end. However in reality too high of a value here just means that you hide the cases of clients that actually died. So similar as above: consider how far a client may fall behind "live" (our head) and then make a number up. for example if we use a burst size of 4 seconds the queue might be 8 or 12 seconds long. But I wouldn't go with much more as a listener that can for example not read from Icecast in 12 seconds likely will not sustain a stable stream even if you give it more time. > What exactly does the slow_listener count in relation to queue -size > indicate? I?ve seen the slow_listeners number grow well beyond the > number of connected listeners: When a listener hist the tail it is considered slow and removed. The infamous "Client [...] has fallen too far behind, removing" error. This just means that they could not keep up. So the value you see is the counter of how often that happened. It is the sum and expected to only grow. The speed of it growing is what is interesting not the value. And even that value needs to be put in context: e.g. when you have many mobile listeners the value is expected to grow faster. When you have listeners all in the same building as your Icecast server you should hardly see the number grow. So if at all you compare that number directly to something compare it to your total amount of listeners, not the current value. :) ? > Right now I am seeing: > listeners > 508 > queue_size > 2191778 > slow_listeners > 1501 If you're having 508 listeners constantly and your server is running for some time 1501 slow listeners wouldn't be too much of an alarm to me. :) > How do I use this data to find the best queue-size and burst-size > settings to keep listeners connected without dropout? I hope my hints help you a bit. :) With best regards, PS: I just realised that a fish and swim example is most appropriate for a Xiph.Org Foundation project. -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephone:???????????+49.3535 490 17 92 Website:?????????????https://www.loewenfelsen.net/ Follow us:???????????https://www.linkedin.com/company/loewenfelsen/ Gesch?ftsf?hrer/CEO: Philipp Schafft L?wenfelsen UG (haftungsbeschr?nkt)?????Registration number: Bickinger Stra?e 21?????????????????????HRB 12308 CB 04916 Herzberg (Elster)?????????????????VATIN/USt-ID: Germany?????????????????????????????????DE305133015 _______________________________________________ Icecast mailing list Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast From tyctor at post.cz Tue Feb 13 10:19:14 2024 From: tyctor at post.cz (tyctor at post.cz) Date: Tue, 13 Feb 2024 11:19:14 +0100 Subject: [Icecast] Listener stats Message-ID: <0e5e8276cbcded3221bbaceba804d6e9a4d16627.camel@post.cz> Hi icecast masters we have script which check every two minutes if stream is available script just use ffprobe to connect and read stream title i have question if/how this connection will count to Listeners or Listeners Peak i am looking forward to your reply tyctor From epirat07 at gmail.com Tue Feb 13 10:33:50 2024 From: epirat07 at gmail.com (epirat07 at gmail.com) Date: Tue, 13 Feb 2024 11:33:50 +0100 Subject: [Icecast] Listener stats In-Reply-To: <0e5e8276cbcded3221bbaceba804d6e9a4d16627.camel@post.cz> References: <0e5e8276cbcded3221bbaceba804d6e9a4d16627.camel@post.cz> Message-ID: <3C2BC455-7421-4AED-ADA4-C520F2058AEC@gmail.com> On 13 Feb 2024, at 11:19, tyctor at post.cz wrote: > Hi icecast masters > > we have script which check every two minutes if stream is available > script just use ffprobe to connect and read stream title > > i have question if/how this connection will count to Listeners or > Listeners Peak It will count like any other listener. There is nothing special going on here why it would not. > > i am looking forward to your reply > > tyctor > > > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From tyctor at post.cz Tue Feb 13 10:51:45 2024 From: tyctor at post.cz (tyctor at post.cz) Date: Tue, 13 Feb 2024 11:51:45 +0100 Subject: [Icecast] Listener stats In-Reply-To: <3C2BC455-7421-4AED-ADA4-C520F2058AEC@gmail.com> References: <0e5e8276cbcded3221bbaceba804d6e9a4d16627.camel@post.cz> <3C2BC455-7421-4AED-ADA4-C520F2058AEC@gmail.com> Message-ID: <2099bad4b5d99cedfd9ae8533b4040f69483e0ab.camel@post.cz> thanks for your reply On Tue, 2024-02-13 at 11:33 +0100, epirat07 at gmail.com wrote: > > > On 13 Feb 2024, at 11:19, tyctor at post.cz?wrote: > > > Hi icecast masters > > > > we have script which check every two minutes if stream is available > > script just use ffprobe to connect and read stream title > > > > i have question if/how this connection will count to Listeners or > > Listeners Peak > > It will count like any other listener. There is nothing special going > on here why it would not. understand, but this is only short (about 2 seconds) connection so in Listeners it will increase about 1 every two minutes, right? and how about Listeners Peak, how this value is counted? > > > > > i am looking forward to your reply > > > > tyctor > > > > > > > > > > _______________________________________________ > > 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 From phschafft at de.loewenfelsen.net Tue Feb 13 11:11:04 2024 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Tue, 13 Feb 2024 11:11:04 +0000 Subject: [Icecast] Listener stats In-Reply-To: <2099bad4b5d99cedfd9ae8533b4040f69483e0ab.camel@post.cz> References: <0e5e8276cbcded3221bbaceba804d6e9a4d16627.camel@post.cz> <3C2BC455-7421-4AED-ADA4-C520F2058AEC@gmail.com> <2099bad4b5d99cedfd9ae8533b4040f69483e0ab.camel@post.cz> Message-ID: Good morning, On Tue, 2024-02-13 at 11:51 +0100, tyctor at post.cz wrote: > On Tue, 2024-02-13 at 11:33 +0100, epirat07 at gmail.com?wrote: > > On 13 Feb 2024, at 11:19, tyctor at post.cz?wrote: > > > we have script which check every two minutes if stream is > > > available > > > script just use ffprobe to connect and read stream title > > > > > > i have question if/how this connection will count to Listeners or > > > Listeners Peak > > > > It will count like any other listener. There is nothing special > > going on here why it would not. as magical as Icecast is, there is little magic on the inside. I'm fully with you. To Icecast any client is a client. Icecast doesn't discriminate by type, kind, resource, or colour of a client. ;) > understand, but this is only short (about 2 seconds) connection > so in Listeners it will increase about 1 every two minutes, right? > and how about Listeners Peak, how this value is counted? Even if it's just two seconds, it is a connection. There are basically three values: * The current listeners: This is how many are connected right now. So your script will increase this by one for said 2 seconds and then it will return to it's old value (given no other listeners connect/disconnect in that time). * The peak listeners: This is the maximum value for the current listeners Icecast has seen since the source mounted. So your script will count here only if it does connect while in a peak situation to begin with. And then it might increase the value by one. * The accumulative sum of all listeners: This is increased by one for every listeners. This includes your script but also for example the infamous "double connections" by Apple devices. While this value is technically correct and often provides a good hint it needs to be taken with a grain of salt. Hope that helps! With best regards, -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephone:???????????+49.3535 490 17 92 Website:?????????????https://www.loewenfelsen.net/ Follow us:???????????https://www.linkedin.com/company/loewenfelsen/ Gesch?ftsf?hrer/CEO: Philipp Schafft L?wenfelsen UG (haftungsbeschr?nkt)?????Registration number: Bickinger Stra?e 21?????????????????????HRB 12308 CB 04916 Herzberg (Elster)?????????????????VATIN/USt-ID: Germany?????????????????????????????????DE305133015 From db76 at riseup.net Sat Feb 24 07:39:55 2024 From: db76 at riseup.net (Damian) Date: Sat, 24 Feb 2024 17:39:55 +1000 Subject: [Icecast] Installing Icecast2 with SSL support Message-ID: <55B0B13D-532A-4F32-8C30-DEB815260088@riseup.net> Hi, I?m currently running Icecast 2.4.4 on Debian 12 which was installed via Debian backports (apt -t buster-backports install icecast2). May I ask if this is still the best way to install Iceast2 with SSL support for Debian? I did read online recently that from Debian 12 onwards, Icecast2 would be available for Debian via the apt package maintainer with SSL already compiled but from my own tests, this still doesn?t appear to be the case. Damian -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsinon24 at gmail.com Sat Feb 24 20:42:15 2024 From: tsinon24 at gmail.com (Thomas Sinon) Date: Sat, 24 Feb 2024 14:42:15 -0600 Subject: [Icecast] WGEN FM Tom Sinon Message-ID: <74185B44-D4CB-42FC-9C64-8AE7F301C443@gmail.com> Good afternoon, We are long users of Icecast, and recently we are hitting 10/11 on stream now listeners. When we get there we get a message that we are exceeding server listeners. Is there a maximum listener count, is there a way to expand the number of listeners? Tom Sinon Program Dir3ctor Sent from my iPad From jordan at subj.am Sat Feb 24 22:06:17 2024 From: jordan at subj.am (Jordan Erickson) Date: Sat, 24 Feb 2024 14:06:17 -0800 Subject: [Icecast] WGEN FM Tom Sinon In-Reply-To: <74185B44-D4CB-42FC-9C64-8AE7F301C443@gmail.com> References: <74185B44-D4CB-42FC-9C64-8AE7F301C443@gmail.com> Message-ID: Take a look at this: https://icecast.org/docs/icecast-2.4.1/config-file.html#limits Cheers, Jordan On 2/24/24 12:42, Thomas Sinon wrote: > Good afternoon, > > We are long users of Icecast, and recently we are hitting 10/11 on stream now listeners. When we get there we get a message that we are exceeding server listeners. Is there a maximum listener count, is there a way to expand the number of listeners? > > Tom Sinon > Program Dir3ctor > Sent from my iPad > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -- https://subj.am/ From db76 at riseup.net Mon Feb 26 23:03:17 2024 From: db76 at riseup.net (Damian) Date: Tue, 27 Feb 2024 09:03:17 +1000 Subject: [Icecast] Reloading the config to pick up new ssl cert Message-ID: Hello, I have a question about reloading the icecast config so that it picks up a renewed ssl certificate without having to restart and kick all connected listeners. I understand that this feature is supported in version 2.5 and I know that reloading via the API is not yet supported in 2.4.4. I read that doing Kill -HUP $PID would reload the config in 2.4.4. and pick up the ssl cert. Can anyone confirm if this is this correct? Damian -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsinon24 at gmail.com Wed Feb 28 17:01:47 2024 From: tsinon24 at gmail.com (Thomas Sinon) Date: Wed, 28 Feb 2024 11:01:47 -0600 Subject: [Icecast] WGEN FM Tom Sinon In-Reply-To: References: Message-ID: <82E5E7B9-620D-4458-89C4-7979C26B0BC2@gmail.com> I found the client limit line. Is there a way to add to the client limit of 10. Sent from my iPad > On Feb 24, 2024, at 4:06?PM, Jordan Erickson wrote: > > ?Take a look at this: https://icecast.org/docs/icecast-2.4.1/config-file.html#limits > > Cheers, > Jordan > > >> On 2/24/24 12:42, Thomas Sinon wrote: >> Good afternoon, >> >> We are long users of Icecast, and recently we are hitting 10/11 on stream now listeners. When we get there we get a message that we are exceeding server listeners. Is there a maximum listener count, is there a way to expand the number of listeners? >> >> Tom Sinon >> Program Dir3ctor >> Sent from my iPad >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast > > -- > https://subj.am/ > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From jordan at subj.am Wed Feb 28 17:37:17 2024 From: jordan at subj.am (Jordan Erickson) Date: Wed, 28 Feb 2024 09:37:17 -0800 Subject: [Icecast] WGEN FM Tom Sinon In-Reply-To: <82E5E7B9-620D-4458-89C4-7979C26B0BC2@gmail.com> References: <82E5E7B9-620D-4458-89C4-7979C26B0BC2@gmail.com> Message-ID: <91f34335-7763-4c05-a5d3-930f68946258@subj.am> Hi Thomas, This is something the administrator of your Icecast server can do. Cheers, Jordan On 2/28/24 09:01, Thomas Sinon wrote: > I found the client limit line. Is there a way to add to the client limit of 10. > Sent from my iPad > >> On Feb 24, 2024, at 4:06?PM, Jordan Erickson wrote: >> >> ?Take a look at this: https://icecast.org/docs/icecast-2.4.1/config-file.html#limits >> >> Cheers, >> Jordan >> >> >>> On 2/24/24 12:42, Thomas Sinon wrote: >>> Good afternoon, >>> >>> We are long users of Icecast, and recently we are hitting 10/11 on stream now listeners. When we get there we get a message that we are exceeding server listeners. Is there a maximum listener count, is there a way to expand the number of listeners? >>> >>> Tom Sinon >>> Program Dir3ctor >>> Sent from my iPad >>> _______________________________________________ >>> Icecast mailing list >>> Icecast at xiph.org >>> http://lists.xiph.org/mailman/listinfo/icecast >> -- >> https://subj.am/ >> >> _______________________________________________ >> 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 -- https://subj.am/