From thomas at ruecker.fi Thu Nov 1 13:46:56 2018 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B._R=c3=bccker?=) Date: Thu, 1 Nov 2018 13:46:56 +0000 Subject: [Icecast] Icecast 2.4.4 - security release Message-ID: <8caac797-9d34-9219-e2fb-741d39f81f2a@ruecker.fi> We released a new version of Icecast. It is a security release and we recommend to update all Icecast installations of versions below 2.4.4 to it. A summary of the changes is listed below, for details please refer to the ChangeLog: https://gitlab.xiph.org/xiph/icecast-server/blob/release-2.4.4/ChangeLog The Xiph.org package repositories have been updated already. Most distributions should start shipping updated Icecast versions soon. All issues have been also addressed in our development master branch. We plan to ship a 2.5 beta 3 in the near future. ## Fixes -?? Fix buffer overflows in URL auth code, [CVE-2018-18820]. [#2342] ??? * This security issue affects all Icecast servers running version 2.4.0, 2.4.1, 2.4.2 or 2.4.3 if there is a "mount" definition that enables URL authentication. ??? * A malicious client could send long HTTP headers, leading to a buffer overflow and potential remote code execution. ??? * The problematic code was introduced in version 2.4.0 and was now brought to our attention by Nick Rolfe of Semmle Security Research Team https://lgtm.com/security -?? Worked around buffer overflows in URL auth's cURL interface. ??? * We currently do not believe that this issue is exploitable. It would require a malicious URL authentication back end server ?to send a crafted payload and make it through libcURL. ??? * If someone manages, please let us know. -?? Do not report hashed user passworts in user list. There is no practical reason to show this to the administrator and it improves security. -?? Fixed segfault in htpasswd auth if no filename is set -?? Fixed a segfault when xsltApplyStylesheet() returns error -?? Do not segfault on malformed Opus streams -?? Global listener count could be negative under certain circumstances. Thanks a lot to Simeon V?lkel (0xBD4E031CDB4043C9) for reporting and investigating the bug. -?? Added code to announce Opus streams as such towards yp servers. ## Downloads Source: http://downloads.xiph.org/releases/icecast/icecast-2.4.4.tar.gz Win32: http://downloads.xiph.org/releases/icecast/icecast_win32_2.4.4.exe [#2342]: https://gitlab.xiph.org/xiph/icecast-server/issues/2342 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From googe at googe.tv Thu Nov 1 19:29:26 2018 From: googe at googe.tv (Googe) Date: Thu, 1 Nov 2018 12:29:26 -0700 Subject: [Icecast] compile Icecast 2.4.4 with Open SSL? Message-ID: <3c45ece6-88e1-7c00-b278-0be3d852c328@googe.tv> How do I compile Icecast 2.4.4 with openssl support? From thomas at ruecker.fi Fri Nov 2 11:46:52 2018 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B._R=c3=bccker?=) Date: Fri, 2 Nov 2018 11:46:52 +0000 Subject: [Icecast] compile Icecast 2.4.4 with Open SSL? In-Reply-To: <3c45ece6-88e1-7c00-b278-0be3d852c328@googe.tv> References: <3c45ece6-88e1-7c00-b278-0be3d852c328@googe.tv> Message-ID: Hi, On 11/01/2018 07:29 PM, Googe wrote: > How do I compile Icecast 2.4.4 with openssl support? Usually that question comes from Ubuntu or Debian users. In which case we recommend: https://wiki.xiph.org/Icecast_Server/Installing_latest_version_(official_Xiph_repositories) Those official Xiph.org packages are built against openSSL. If you are on some unrelated distribution, all you need to ensure is the openSSL headers are installed. Br, TBR From pm at nowster.me.uk Fri Nov 2 12:26:12 2018 From: pm at nowster.me.uk (Paul Martin) Date: Fri, 2 Nov 2018 12:26:12 +0000 Subject: [Icecast] compile Icecast 2.4.4 with Open SSL? In-Reply-To: References: <3c45ece6-88e1-7c00-b278-0be3d852c328@googe.tv> Message-ID: <20181102122612.GB20316@thinkpad.nowster.org.uk> On Fri, Nov 02, 2018 at 11:46:52AM +0000, Thomas B. R?cker wrote: > Usually that question comes from Ubuntu or Debian users. > In which case we recommend: > https://wiki.xiph.org/Icecast_Server/Installing_latest_version_(official_Xiph_repositories) > Those official Xiph.org packages are built against openSSL. Could someone kick the build process, please? 2.4.2-2 is the latest "Debian testing" there. http://download.opensuse.org/repositories/multimedia:/xiph/Debian_Testing/ PS. Debian has just updated to 2.4.4: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912611#17 -- Paul Martin From thomas at ruecker.fi Fri Nov 2 14:03:21 2018 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B._R=c3=bccker?=) Date: Fri, 2 Nov 2018 14:03:21 +0000 Subject: [Icecast] compile Icecast 2.4.4 with Open SSL? In-Reply-To: <20181102122612.GB20316@thinkpad.nowster.org.uk> References: <3c45ece6-88e1-7c00-b278-0be3d852c328@googe.tv> <20181102122612.GB20316@thinkpad.nowster.org.uk> Message-ID: <06ec7e52-552c-6ca8-76db-d84bea8edc54@ruecker.fi> Hi, On 11/02/2018 12:26 PM, Paul Martin wrote: > On Fri, Nov 02, 2018 at 11:46:52AM +0000, Thomas B. R?cker wrote: >> Usually that question comes from Ubuntu or Debian users. >> In which case we recommend: >> https://wiki.xiph.org/Icecast_Server/Installing_latest_version_(official_Xiph_repositories) >> Those official Xiph.org packages are built against openSSL. > Could someone kick the build process, please? > > 2.4.2-2 is the latest "Debian testing" there. Testing is currently stuck because the resolver found two different options for fakeroot. Didn't get around to fixing that in OBS project configuration yet. It's going to happen today or tomorrow though. > PS. Debian has just updated to 2.4.4: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912611#17 Great, we had them on board early to make sure updates go out timely. Br, TBR From thomas at ruecker.fi Fri Nov 2 15:31:05 2018 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B._R=c3=bccker?=) Date: Fri, 2 Nov 2018 15:31:05 +0000 Subject: [Icecast] compile Icecast 2.4.4 with Open SSL? In-Reply-To: <06ec7e52-552c-6ca8-76db-d84bea8edc54@ruecker.fi> References: <3c45ece6-88e1-7c00-b278-0be3d852c328@googe.tv> <20181102122612.GB20316@thinkpad.nowster.org.uk> <06ec7e52-552c-6ca8-76db-d84bea8edc54@ruecker.fi> Message-ID: <9ed8c4e2-1b8a-1499-d0d3-c66d33408651@ruecker.fi> Hi, On 11/02/2018 02:03 PM, Thomas B. R?cker wrote: > On 11/02/2018 12:26 PM, Paul Martin wrote: >> On Fri, Nov 02, 2018 at 11:46:52AM +0000, Thomas B. R?cker wrote: >>> Usually that question comes from Ubuntu or Debian users. >>> In which case we recommend: >>> https://wiki.xiph.org/Icecast_Server/Installing_latest_version_(official_Xiph_repositories) >>> Those official Xiph.org packages are built against openSSL. >> Could someone kick the build process, please? >> >> 2.4.2-2 is the latest "Debian testing" there. > Testing is currently stuck because the resolver found two different > options for fakeroot. This is now resolved and repositories have synced to 2.4.4: https://download.opensuse.org/repositories/multimedia:/xiph/Debian_Testing/ Cheers, TBR PS: Fedora Rawhide packages fail to build, but it looks like that's due to an inconsistent repository state, nothing I can do. It should build once that gets resolved by someone. If someone needs rawhide, please use the SRPM from the FC29 repository. From jeffares.robert at gmail.com Fri Nov 2 22:32:46 2018 From: jeffares.robert at gmail.com (Robert Jeffares) Date: Sat, 3 Nov 2018 11:32:46 +1300 Subject: [Icecast] Configure Ubuntu Server 16.04 for icecast2 In-Reply-To: References: <5a219138-be51-77e9-ae60-4d4f86d344f7@gmail.com> Message-ID: <9c322893-83d1-3d59-34f0-1e4ffbe07221@gmail.com> Bonjour, *Upload: 282.95 Mbit/s* is going to choke at about 5 listeners * * You need a streaming server provider. https://shoutca.st/ is an example but there are many. Don't buy 5k listeners buy 100 and see how it goes. *regards* *Robert* * * * * On 22/10/18 12:03 AM, Abdelkader BKF wrote: > Hi, > Thank you so much for your reply, > I've a dedicated server in OVH, where I have done speed test for the > server : > > *bkf at xxxxx ~> speedtest-cli > Retrieving speedtest.net configuration... > Retrieving speedtest.net server list... > Testing from OVH SAS (x.x.x.x)... > Selecting best server based on latency... > Hosted by fdcservers.net (Paris) [1.88 km]: > 6.488 ms > Testing download speed........................................ > Download: 900.46 Mbit/s > Testing upload speed.................................................. > Upload: 282.95 Mbit/s* > > Is it enough for up 5k listeners ? Could you please give me best > Providers for streaming ? > > Thanks. > Regards > > On Sun, Oct 21, 2018 at 12:53 AM Robert Jeffares > > wrote: > > Hi BKF, > > you can configure icecast to serve thousands of listeners but it's > not going to happen on anything less then an industrial strength > internet connection. > > If you have ADSL you can probably handle 5 listeners maybe 10 on > an average service. > > If you have VDSL increase that to 15 maybe. > > If you have fibre it might do 25. > > It all depends on the service provided by your ISP and the > condition of the cabling between the local switch and your location. > > They control how much data you can send and recieve even on " > unlomited " > > Then it depends? on the modem router, and your in house network, > although these are less likely problem areas. > > If you want 5000 listeners you have to send audio to a Streaming > Service Provider who has a BIG internet upload capability which > costs money. > > There are some that charge rather low rates for 200-1000 > connections because they know that while you pay for capability > very few stations have more then one or two listeners on line at > any time. > > I support one that has up to 200 listeners and we may be at 40 or > so except when there is some critical news breaking which takes us > over the 100. > > We have a feed for an app and a feed for tunein and a feed for the > website. The app has the highest usage > > On 21/10/18 12:17 AM, Abdelkader BKF wrote: >> Hi all, >> First of all, thank you for supporting us. >> I've installed Libretime (https://github.com/LibreTime/libretime) >> which user Icecast2 on Ubuntu Server 16.04. >> I've also developed a mobile application to listen to stream >> myhost:8000/mount. >> My problem is when the number of listeners increases up 500 (On >> live streaming with butt), the application blockes, and I hardly >> get info from myhost:8000/status-json.xsl. >> My question is : How shoud I configure my Ubuntu / Icecast / >> Liquidsoup to allow more than 5000 listeners to listen music >> without any issue. >> >> Thanks. >> >> Regards. >> >> BKF-Dev >> >> >> _______________________________________________ >> 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 > > > > -- > BOUKHELF Abdelkader > Analyst / Developer Software Engineer - (Information System) > Skype : akaderb > Mobile : (+213) 556 45 38 71. > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at alexhackney.com Fri Nov 2 23:41:30 2018 From: me at alexhackney.com (Alex Hackney) Date: Fri, 2 Nov 2018 19:41:30 -0400 Subject: [Icecast] Custom Hooks Message-ID: I am looking for a way that I can use to send a hook to my api when particular things happen. For instance, i need to know when listeners or sources connect or disconnect and when song meta data changes on a stream. I see this data on the log and can write a script to do it by monitoring the log but does icecast have a better way? Almost looks like the auth block could do it but I don't want to prompt listeners for a login. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at stationplaylist.com Sat Nov 3 00:59:22 2018 From: ross at stationplaylist.com (Ross Levis) Date: Sat, 3 Nov 2018 13:59:22 +1300 Subject: [Icecast] Configure Ubuntu Server 16.04 for icecast2 In-Reply-To: <9c322893-83d1-3d59-34f0-1e4ffbe07221@gmail.com> References: <5a219138-be51-77e9-ae60-4d4f86d344f7@gmail.com> <9c322893-83d1-3d59-34f0-1e4ffbe07221@gmail.com> Message-ID: <009001d47310$76c01dc0$64405940$@com> You have confused megabits for kilobits. The number of listeners depends on the bitrate of the stream. Assuming a 64kb/s stream, 282.95 Mb/s will support 4400 listeners, but more likely 4000. Ross. From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Robert Jeffares Sent: Saturday, 3 November 2018 11:33 a.m. To: icecast at xiph.org Subject: Re: [Icecast] Configure Ubuntu Server 16.04 for icecast2 Bonjour, Upload: 282.95 Mbit/s is going to choke at about 5 listeners You need a streaming server provider. https://shoutca.st/ is an example but there are many. Don't buy 5k listeners buy 100 and see how it goes. regards Robert On 22/10/18 12:03 AM, Abdelkader BKF wrote: Hi, Thank you so much for your reply, I've a dedicated server in OVH, where I have done speed test for the server : bkf at xxxxx ~> speedtest-cli Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from OVH SAS (x.x.x.x)... Selecting best server based on latency... Hosted by fdcservers.net (Paris) [1.88 km]: 6.488 ms Testing download speed........................................ Download: 900.46 Mbit/s Testing upload speed.................................................. Upload: 282.95 Mbit/s Is it enough for up 5k listeners ? Could you please give me best Providers for streaming ? Thanks. Regards On Sun, Oct 21, 2018 at 12:53 AM Robert Jeffares wrote: Hi BKF, you can configure icecast to serve thousands of listeners but it's not going to happen on anything less then an industrial strength internet connection. If you have ADSL you can probably handle 5 listeners maybe 10 on an average service. If you have VDSL increase that to 15 maybe. If you have fibre it might do 25. It all depends on the service provided by your ISP and the condition of the cabling between the local switch and your location. They control how much data you can send and recieve even on " unlomited " Then it depends on the modem router, and your in house network, although these are less likely problem areas. If you want 5000 listeners you have to send audio to a Streaming Service Provider who has a BIG internet upload capability which costs money. There are some that charge rather low rates for 200-1000 connections because they know that while you pay for capability very few stations have more then one or two listeners on line at any time. I support one that has up to 200 listeners and we may be at 40 or so except when there is some critical news breaking which takes us over the 100. We have a feed for an app and a feed for tunein and a feed for the website. The app has the highest usage On 21/10/18 12:17 AM, Abdelkader BKF wrote: Hi all, First of all, thank you for supporting us. I've installed Libretime (https://github.com/LibreTime/libretime) which user Icecast2 on Ubuntu Server 16.04. I've also developed a mobile application to listen to stream myhost:8000/mount. My problem is when the number of listeners increases up 500 (On live streaming with butt), the application blockes, and I hardly get info from myhost:8000/status-json.xsl. My question is : How shoud I configure my Ubuntu / Icecast / Liquidsoup to allow more than 5000 listeners to listen music without any issue. Thanks. Regards. BKF-Dev _______________________________________________ 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 -- BOUKHELF Abdelkader Analyst / Developer Software Engineer - (Information System) Skype : akaderb Mobile : (+213) 556 45 38 71. _______________________________________________ Icecast mailing list Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast -------------- next part -------------- An HTML attachment was scrubbed... URL: From mickael.monsieur at gmail.com Sat Nov 3 19:33:18 2018 From: mickael.monsieur at gmail.com (Mickael MONSIEUR) Date: Sat, 3 Nov 2018 20:33:18 +0100 Subject: [Icecast] limit-rate Message-ID: Hi, Where is the mount option 'limit-rate' in the current version? I checked in cfgfile.c and in the documentation, no mention. Yet this option did exist at one time: http://lists.xiph.org/pipermail/icecast/2010-October/011703.html http://lists.xiph.org/pipermail/icecast/2009-January/011391.html I try to limit the bitrate of a mount-point, is there another solution? Do you know why this option has disappeared, and from which version? Best regards, Mickael -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at ruecker.fi Sat Nov 3 20:47:28 2018 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B._R=c3=bccker?=) Date: Sat, 3 Nov 2018 20:47:28 +0000 Subject: [Icecast] limit-rate In-Reply-To: References: Message-ID: <62a74e10-5262-041b-1e07-4a8c162c9a0b@ruecker.fi> Hi, On 11/03/2018 07:33 PM, Mickael MONSIEUR wrote: > Hi, > Where is the mount option 'limit-rate' in the current version? > I checked in cfgfile.c and in the documentation, no mention. This option does not exist. > Yet this option did exist at one time: > http://lists.xiph.org/pipermail/icecast/2010-October/011703.html > http://lists.xiph.org/pipermail/icecast/2009-January/011391.html > This option never existed in official Icecast versions. > I try to limit the bitrate of a mount-point, is there another solution? Depends on what you are trying to achieve. There are several ways. One is e.g. to use a combination of iptables and tc. What's the problem you are solving? > Do you know why this option has disappeared, and from which version? Again, this has never existed in a stable and official Icecast version. Cheers, TBR From mickael.monsieur at gmail.com Sat Nov 3 21:53:56 2018 From: mickael.monsieur at gmail.com (Mickael MONSIEUR) Date: Sat, 3 Nov 2018 22:53:56 +0100 Subject: [Icecast] limit-rate In-Reply-To: <62a74e10-5262-041b-1e07-4a8c162c9a0b@ruecker.fi> References: <62a74e10-5262-041b-1e07-4a8c162c9a0b@ruecker.fi> Message-ID: Hello, Thank you for your response. It is on the kh version.. https://github.com/karlheyes/icecast-kh Le sam. 3 nov. 2018 ? 21:47, Thomas B. R?cker a ?crit : > Hi, > > On 11/03/2018 07:33 PM, Mickael MONSIEUR wrote: > > Hi, > > Where is the mount option 'limit-rate' in the current version? > > I checked in cfgfile.c and in the documentation, no mention. > > This option does not exist. > > > > Yet this option did exist at one time: > > http://lists.xiph.org/pipermail/icecast/2010-October/011703.html > > http://lists.xiph.org/pipermail/icecast/2009-January/011391.html > > > > This option never existed in official Icecast versions. > > > > I try to limit the bitrate of a mount-point, is there another solution? > > Depends on what you are trying to achieve. There are several ways. > One is e.g. to use a combination of iptables and tc. > What's the problem you are solving? > > > > Do you know why this option has disappeared, and from which version? > > Again, this has never existed in a stable and official Icecast version. > > > Cheers, > TBR > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at ruecker.fi Sun Nov 4 11:54:16 2018 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B._R=c3=bccker?=) Date: Sun, 4 Nov 2018 11:54:16 +0000 Subject: [Icecast] limit-rate In-Reply-To: References: <62a74e10-5262-041b-1e07-4a8c162c9a0b@ruecker.fi> Message-ID: <194070aa-e79c-fa7c-2b78-af1e9d34ab44@ruecker.fi> On 11/03/2018 09:53 PM, Mickael MONSIEUR wrote: > Hello, > Thank you for your response. > It is on the kh version.. That's not a version. That's completely different software at this point. It's also not Xiph.org, but published by Karl. TBR > Le?sam. 3 nov. 2018 ??21:47, Thomas B. R?cker > a ?crit?: > > Hi, > > On 11/03/2018 07:33 PM, Mickael MONSIEUR wrote: > > Hi, > > Where is the mount option 'limit-rate' in the current version? > > I checked in cfgfile.c and in the documentation, no mention. > > This option does not exist. > > > > Yet this option did exist at one time: > > http://lists.xiph.org/pipermail/icecast/2010-October/011703.html > > http://lists.xiph.org/pipermail/icecast/2009-January/011391.html > > > > This option never existed in official Icecast versions. > > > > I try to limit the bitrate of a mount-point, is there another > solution? > > Depends on what you are trying to achieve. There are several ways. > One is e.g. to use a combination of iptables and tc. > What's the problem you are solving? > > > > Do you know why this option has disappeared, and from which version? > > Again, this has never existed in a stable and official Icecast > version. > > > Cheers, > TBR > > _______________________________________________ > 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 thomas at ruecker.fi Sun Nov 4 11:57:48 2018 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B._R=c3=bccker?=) Date: Sun, 4 Nov 2018 11:57:48 +0000 Subject: [Icecast] Custom Hooks In-Reply-To: References: Message-ID: On 11/02/2018 11:41 PM, Alex Hackney wrote: > I am looking for a way that I can use to send a hook to my api when > particular things happen. > > For instance, i need to know when listeners or sources connect or > disconnect and when song meta data changes on a stream. > > I see this data on the log and can write a script to do it by > monitoring the log but does icecast have a better way? > > Almost looks like the auth block could do it but I don't want to > prompt listeners for a login. > That's actually how you do it. You use the URL-auth backend and always return positive authentication. Please make sure that you are running version 2.4.4 though. Older versions have a security issue in the URL-auth code! Cheers, TBR From artuch at speedy.com.ar Sun Nov 4 14:26:11 2018 From: artuch at speedy.com.ar (=?ISO-8859-1?Q?Jos=E9?= Luis Artuch) Date: Sun, 04 Nov 2018 11:26:11 -0300 Subject: [Icecast] compile Icecast 2.4.4 with Open SSL? In-Reply-To: References: <3c45ece6-88e1-7c00-b278-0be3d852c328@googe.tv> Message-ID: <1541341571.2376.2.camel@speedy.com.ar> El vie, 02-11-2018 a las 11:46 +0000, Thomas B. R?cker escribi?: > Hi, > > On 11/01/2018 07:29 PM, Googe wrote: > > How do I compile Icecast 2.4.4 with openssl support? > > Usually that question comes from Ubuntu or Debian users. > In which case we recommend: > https://wiki.xiph.org/Icecast_Server/Installing_latest_version_(offic > ial_Xiph_repositories) > Those official Xiph.org packages are built against openSSL. Thanks Thomas, finally !! > > If you are on some unrelated distribution, all you need to ensure is > the > openSSL headers are installed. > > Br, > > TBR > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From pm at nowster.me.uk Sun Nov 4 15:41:50 2018 From: pm at nowster.me.uk (Paul Martin) Date: Sun, 4 Nov 2018 15:41:50 +0000 Subject: [Icecast] limit-rate In-Reply-To: <194070aa-e79c-fa7c-2b78-af1e9d34ab44@ruecker.fi> References: <62a74e10-5262-041b-1e07-4a8c162c9a0b@ruecker.fi> <194070aa-e79c-fa7c-2b78-af1e9d34ab44@ruecker.fi> Message-ID: <20181104154150.GA27042@thinkpad.nowster.org.uk> On Sun, Nov 04, 2018 at 11:54:16AM +0000, Thomas B. R?cker wrote: > That's not a version. > That's completely different software at this point. > It's also not Xiph.org, but published by Karl. It is a desirable feature, though. The use case is a server with one or more external feeds, where those feeds can be intermittent. You want a fallback-mount to a static file for when the feed drops, but you also want the listeners to go back to the live feed soon after it returns. Unfortunately, the way Icecast2 works with static files is that it feeds as much as the listener's player software buffer can take, meaning a huge spike in bandwidth use when it falls back to a static file, and (more importantly) a huge lag in returning to the correct feed when that reconnects. The way I'm working round this at the moment is to have an instance of liquidsoap on the same server as Icecast, encoding a single static file as a set of continually running fallback-mount feeds, with the same encoder settings as the feeds they're guarding. This is wasteful in resources (memory and CPU) for what could be pre-encoded static files if Icecast had some sort of rate limitation on feeding out static files. -- Paul Martin From phschafft at de.loewenfelsen.net Mon Nov 5 10:26:51 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Mon, 05 Nov 2018 10:26:51 +0000 Subject: [Icecast] On bitrate and time [WAS: Re: limit-rate] In-Reply-To: <20181104154150.GA27042@thinkpad.nowster.org.uk> References: <62a74e10-5262-041b-1e07-4a8c162c9a0b@ruecker.fi> <194070aa-e79c-fa7c-2b78-af1e9d34ab44@ruecker.fi> <20181104154150.GA27042@thinkpad.nowster.org.uk> Message-ID: <1541413611.1925.295.camel@de.loewenfelsen.net> Good morning, thank you very much for your feedback! On Sun, 2018-11-04 at 15:41 +0000, Paul Martin wrote: > On Sun, Nov 04, 2018 at 11:54:16AM +0000, Thomas B. R?cker wrote: > > > That's not a version. > > That's completely different software at this point. > > It's also not Xiph.org, but published by Karl. > > It is a desirable feature, though. It isn't. And here is why: There are several problems with such a limit. Let's start by how to detect it: Media streaming has inherently changes in bitrate. This happens due to mainly three factors: * For any modern codec the codec tries to compress the actual information within the signal. As the amount of information varies over time the bitrate changes. This is something that happends on the tens of milliseconds to the hundreds of seconds scale. * Metadata is transported alongside actual data. Such metadata includes not only title updates but also updates for encoder settings. Metadata updates are point-in-time events that can have from a few byte (e.g. title updates), or a few more bytes (encoder settings) up to a few MB (huge cover art). * Framing related modulation. Example of this are e.g. filling container frames or TCP corking. The scale of this depends on the bitrate (yes, this is the x* = f(x) problem class.). It's normally on the hundreds of milliseconds to few seconds scale. To calculate a good bitrate estimation (and that is what it is, an estimation as we are bound to causality) we need at least a few seconds of window. And even that will hardly work for point-in-time events as they represent Dirac impulses (which can be hardly detected as they are flatted into bitrate "plateau"s by the physical limits of the transport). So, detecting bitrate is already on the scale of several seconds, maybe minutes. Not very helpful for most usecases in a close-to-realtime eco system. Next let's look at what this represents: The bitrate depends on a lot of factors. It is relevant for transport capacity planing (e.g. how much listeners you can handle on a given connection). It is also relevant for buffer control (e.g. burst size, how long may transmission breaks are, ...). However it does not directly represent time. One might think that: t_segment = segment size / bitrate. However as shown above this only works for t_segment being very long. Please let me also note that bitrate does not correlate directly to quality. But just like it is a bit more complex with time it is with quality. So maybe this is a topic for another E-Mail. Let's look on what we would do with the information: You suggested to implement some "limit". So the question is what to do when this limited (measured in any way) is reached? Possibilities are: * We could make a log entry. This could be helpful for debugging. Maybe. While I see some use cases I think it's not worth the work to implement it. If you're interested you can use any download tool (browser, wget, curl, ...) to have a life reading! * We could drop the stream as it uses more resources than agreed on. Sounds like a feature for stream providers. Yet with all the problems of measuring it, it would likely generate false positives OR be too relaxed. From all I know about streaming provides they are more interested in stability of the service than minor accounting errors. (And they can still use the total number of served bytes for accounting. Which would be the best way to do it anway!) * We could pause the stream to throttle the bitrate to it's limit. (This is what you suggest, if I understand you correctly.) This would somehow work. For a small class of problems: Hardly any metadata in streams, hardly changing information within the signal (read: noise, and boring music; do NOT read: speech, fade-in/fade-out, dynamic music, periods of silence, ...), and controlled framing, and transport. If implemented, reality will come sooner than later and break such a setup in one way or another. General notes about throttling: All kinds of throttling add another clock to the system. This works fine with static files (as they do not provide a clock themselfs). So they end up with exactly one clock (which is what you want) (see also below). It does however not work well for live streamed content as it already has a clock signal. It will result in a man-with-two-watches problem PLUS that you will all the time use both. Also note that in reality clocks are in the 'bad' state (they report the wrong time). E.g. clock drift will make the error grow over time until at some point the buffers can not compensate. Clock errors in reality are normally up to 1%. However I have seen 5%. As you only talk about static files this is not much of a problem for you. However if there is a general option it will become for other people. > The use case is a server with one or more external feeds, where those > feeds can be intermittent. You want a fallback-mount to a static file > for when the feed drops, but you also want the listeners to go back to > the live feed soon after it returns. > > Unfortunately, the way Icecast2 works with static files is that it > feeds as much as the listener's player software buffer can take, > meaning a huge spike in bandwidth use when it falls back to a static > file, and (more importantly) a huge lag in returning to the correct > feed when that reconnects. > > The way I'm working round this at the moment is to have an instance of > liquidsoap on the same server as Icecast, encoding a single static > file as a set of continually running fallback-mount feeds, with the > same encoder settings as the feeds they're guarding. This is wasteful > in resources (memory and CPU) for what could be pre-encoded static > files if Icecast had some sort of rate limitation on feeding out > static files. About your actual problems: We are currently running a project with some external partner that will future versions of Icecast allow to run format-aware *time based* throttling for fserv (static files) content (including fallbacks). This will be a feature post Icecast 2.5 beta3. If you're in need for a more swift solution feel free to write me off-list to discuss options. I hope that this E-Mail helps you and also our dear fellows reading this list. With best regards, -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephon: +49.3535 490 17 92 L?wenfelsen UG (haftungsbeschr?nkt) Registration number: Bickinger Stra?e 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From HB at LightHouseNova.com Tue Nov 6 15:27:41 2018 From: HB at LightHouseNova.com (Hans Brost) Date: Tue, 06 Nov 2018 07:27:41 -0800 Subject: [Icecast] Installing IceCast2 on CentOS 6 / CPanel Message-ID: <5BE1B2ED.6090901@LightHouseNova.com> Was hoping to get some updated instructions for this. Have access to a dedicated server. The info on the web seems to be outdated.....some of the links are DOA..... There was one simple install, but not sure if it would work: This tutorial explains how to install icecast kh10 server on centos 6 server # cd /usr/src # wget https://github.com/karlheyes/icecast-kh/archive/icecast-2.4.0-kh1.tar.gz # tar -zxf icecast-2.4.0-kh1.tar.gz # cd icecast-kh-icecast-2.4.0-kh1 # ./configure;make CFLAGS=?-D_XOPEN_SOURCE=600? # make install if this is centovacast server you many need to run this to register new package # /usr/local/centovacast/sbin/enable_package ICECAST /usr/local/bin/icecast now you are done ? Any help would be much appreciated From epirat07 at gmail.com Tue Nov 6 15:37:44 2018 From: epirat07 at gmail.com (Marvin Scholz) Date: Tue, 06 Nov 2018 16:37:44 +0100 Subject: [Icecast] Installing IceCast2 on CentOS 6 / CPanel In-Reply-To: <5BE1B2ED.6090901@LightHouseNova.com> References: <5BE1B2ED.6090901@LightHouseNova.com> Message-ID: <0598B250-C326-4F6F-B16B-4A5ABC561B1A@gmail.com> On 6 Nov 2018, at 16:27, Hans Brost wrote: > Was hoping to get some updated instructions for this. > > Have access to a dedicated server. > > The info on the web seems to be outdated.....some of the links are > DOA..... > > There was one simple install, but not sure if it would work: > > This tutorial explains how to install icecast kh10 server on centos 6 > server > > # cd /usr/src > # wget > https://github.com/karlheyes/icecast-kh/archive/icecast-2.4.0-kh1.tar.gz This support list is not for the -kh fork of Icecast. > # tar -zxf icecast-2.4.0-kh1.tar.gz > # cd icecast-kh-icecast-2.4.0-kh1 > # ./configure;make CFLAGS=?-D_XOPEN_SOURCE=600? > # make install > > if this is centovacast server you many need to run this to register > new package > > # /usr/local/centovacast/sbin/enable_package ICECAST > /usr/local/bin/icecast > > now you are done ? > > Any help would be much appreciated > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From jordan at coolmic.net Tue Nov 6 16:25:01 2018 From: jordan at coolmic.net (Jordan Erickson) Date: Tue, 6 Nov 2018 08:25:01 -0800 Subject: [Icecast] Installing IceCast2 on CentOS 6 / CPanel In-Reply-To: <5BE1B2ED.6090901@LightHouseNova.com> References: <5BE1B2ED.6090901@LightHouseNova.com> Message-ID: Hi Hans, Icecast-KH is *not* the official Icecast and is not supported here. Please refer to KH specific support channels with questions. Sincerely, Jordan On 11/6/18 7:27 AM, Hans Brost wrote: > Was hoping to get some updated instructions for this. > > Have access to a dedicated server. > > The info on the web seems to be outdated.....some of the links are DOA..... > > There was one simple install, but not sure if it would work: > > This tutorial explains how to install icecast kh10 server on centos 6 > server > > # cd /usr/src > # wget > https://github.com/karlheyes/icecast-kh/archive/icecast-2.4.0-kh1.tar.gz > # tar -zxf icecast-2.4.0-kh1.tar.gz > # cd icecast-kh-icecast-2.4.0-kh1 > # ./configure;make CFLAGS=?-D_XOPEN_SOURCE=600? > # make install > > if this is centovacast server you many need to run this to register new > package > > # /usr/local/centovacast/sbin/enable_package ICECAST /usr/local/bin/icecast > > now you are done ? > > Any help would be much appreciated > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From thomas at ruecker.fi Wed Nov 7 09:33:28 2018 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B._R=c3=bccker?=) Date: Wed, 7 Nov 2018 09:33:28 +0000 Subject: [Icecast] Installing IceCast2 on CentOS 6 / CPanel In-Reply-To: <5BE1B2ED.6090901@LightHouseNova.com> References: <5BE1B2ED.6090901@LightHouseNova.com> Message-ID: <2ff980a4-8937-0584-1d1e-d22df570a564@ruecker.fi> Hi, On 11/06/2018 03:27 PM, Hans Brost wrote: > Was hoping to get some updated instructions for this. > > Have access to a dedicated server. > > The info on the web seems to be outdated.....some of the links are > DOA..... Xiph.org provides official packages for CentOS: https://download.opensuse.org/repositories/multimedia:/xiph/CentOS_6/ https://download.opensuse.org/repositories/multimedia:/xiph/CentOS_7/ Just add the repository corresponding to your distribution to your package management. There's also EPEL, which provides many packages specifically for RHEL/CentOS: https://fedoraproject.org/wiki/EPEL (Their Icecast is at 2.4.3, so don't use it with URL-auth enabled!) Cheers, Thomas From petr.pisar at atlas.cz Wed Nov 7 10:06:11 2018 From: petr.pisar at atlas.cz (Petr Pisar) Date: Wed, 7 Nov 2018 11:06:11 +0100 Subject: [Icecast] Installing IceCast2 on CentOS 6 / CPanel In-Reply-To: <2ff980a4-8937-0584-1d1e-d22df570a564@ruecker.fi> References: <5BE1B2ED.6090901@LightHouseNova.com> <2ff980a4-8937-0584-1d1e-d22df570a564@ruecker.fi> Message-ID: <20181107100608.GA4664@dhcp-0-146.brq.redhat.com> On Wed, Nov 07, 2018 at 09:33:28AM +0000, Thomas B. R?cker wrote: > There's also EPEL, which provides many packages specifically for > RHEL/CentOS: > https://fedoraproject.org/wiki/EPEL > (Their Icecast is at 2.4.3, so don't use it with URL-auth enabled!) > Un updated package is on the way . After a testing period, 2.4.4 will be available for EPEL users. (Until then user's can install it after enabling updates-testing repository ). -- Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From thomas at ruecker.fi Wed Nov 7 12:45:57 2018 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B._R=c3=bccker?=) Date: Wed, 7 Nov 2018 12:45:57 +0000 Subject: [Icecast] Installing IceCast2 on CentOS 6 / CPanel In-Reply-To: <20181107100608.GA4664@dhcp-0-146.brq.redhat.com> References: <5BE1B2ED.6090901@LightHouseNova.com> <2ff980a4-8937-0584-1d1e-d22df570a564@ruecker.fi> <20181107100608.GA4664@dhcp-0-146.brq.redhat.com> Message-ID: On 11/07/2018 10:06 AM, Petr Pisar wrote: > On Wed, Nov 07, 2018 at 09:33:28AM +0000, Thomas B. R?cker wrote: >> There's also EPEL, which provides many packages specifically for >> RHEL/CentOS: >> https://fedoraproject.org/wiki/EPEL >> (Their Icecast is at 2.4.3, so don't use it with URL-auth enabled!) >> > Un updated package is on the way > . After > a testing period, 2.4.4 will be available for EPEL users. (Until then user's > can install it after enabling updates-testing repository > ). Great to hear! Thanks! TBR -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From me at alexhackney.com Wed Nov 7 13:08:04 2018 From: me at alexhackney.com (Alex Hackney) Date: Wed, 7 Nov 2018 08:08:04 -0500 Subject: [Icecast] Custom Hooks In-Reply-To: References: Message-ID: When I stream with winamp, it appears to ask for a username and password Everytime. If I just set the return to true no matter what, will it prevent the client from asking for a password? On Sun, Nov 4, 2018, 06:57 Thomas B. R?cker > > On 11/02/2018 11:41 PM, Alex Hackney wrote: > > I am looking for a way that I can use to send a hook to my api when > > particular things happen. > > > > For instance, i need to know when listeners or sources connect or > > disconnect and when song meta data changes on a stream. > > > > I see this data on the log and can write a script to do it by > > monitoring the log but does icecast have a better way? > > > > Almost looks like the auth block could do it but I don't want to > > prompt listeners for a login. > > > > That's actually how you do it. You use the URL-auth backend and always > return positive authentication. > > Please make sure that you are running version 2.4.4 though. Older > versions have a security issue in the URL-auth code! > > Cheers, > > TBR > _______________________________________________ > 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 Wed Nov 7 14:38:24 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Wed, 07 Nov 2018 14:38:24 +0000 Subject: [Icecast] Custom Hooks In-Reply-To: References: Message-ID: <1541601504.1925.328.camel@de.loewenfelsen.net> Good afternoon, On Wed, 2018-11-07 at 08:08 -0500, Alex Hackney wrote: > When I stream with winamp, it appears to ask for a username and password > Everytime. If I just set the return to true no matter what, will it prevent > the client from asking for a password? This sounds like there is a configuration problem. Icecast by itself does not send a 401 without a negative reply from the server (or a backend failure). Maybe you can share your block (with passwords removed (if any)) with us? Please also check your error.log for any problems. Related lines should include "auth" somewhere in them. With best regards, > On Sun, Nov 4, 2018, 06:57 Thomas B. R?cker > > > > > > On 11/02/2018 11:41 PM, Alex Hackney wrote: > > > I am looking for a way that I can use to send a hook to my api when > > > particular things happen. > > > > > > For instance, i need to know when listeners or sources connect or > > > disconnect and when song meta data changes on a stream. > > > > > > I see this data on the log and can write a script to do it by > > > monitoring the log but does icecast have a better way? > > > > > > Almost looks like the auth block could do it but I don't want to > > > prompt listeners for a login. > > > > > > > That's actually how you do it. You use the URL-auth backend and always > > return positive authentication. > > > > Please make sure that you are running version 2.4.4 though. Older > > versions have a security issue in the URL-auth code! -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephon: +49.3535 490 17 92 L?wenfelsen UG (haftungsbeschr?nkt) Registration number: Bickinger Stra?e 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From HB at LightHouseNova.com Wed Nov 7 16:48:59 2018 From: HB at LightHouseNova.com (Hans Brost) Date: Wed, 07 Nov 2018 08:48:59 -0800 Subject: [Icecast] Installing IceCast2 on CentOS 6 / CPanel In-Reply-To: <2ff980a4-8937-0584-1d1e-d22df570a564@ruecker.fi> References: <5BE1B2ED.6090901@LightHouseNova.com> <2ff980a4-8937-0584-1d1e-d22df570a564@ruecker.fi> Message-ID: <5BE3177B.1040703@LightHouseNova.com> An HTML attachment was scrubbed... URL: From HB at LightHouseNova.com Wed Nov 7 16:50:03 2018 From: HB at LightHouseNova.com (Hans Brost) Date: Wed, 07 Nov 2018 08:50:03 -0800 Subject: [Icecast] Installing IceCast2 on CentOS 6 / CPanel In-Reply-To: <20181107100608.GA4664@dhcp-0-146.brq.redhat.com> References: <5BE1B2ED.6090901@LightHouseNova.com> <2ff980a4-8937-0584-1d1e-d22df570a564@ruecker.fi> <20181107100608.GA4664@dhcp-0-146.brq.redhat.com> Message-ID: <5BE317BB.5020906@LightHouseNova.com> An HTML attachment was scrubbed... URL: From me at alexhackney.com Thu Nov 8 17:45:33 2018 From: me at alexhackney.com (Alex Hackney) Date: Thu, 8 Nov 2018 12:45:33 -0500 Subject: [Icecast] Custom Hooks In-Reply-To: <1541601504.1925.328.camel@de.loewenfelsen.net> References: <1541601504.1925.328.camel@de.loewenfelsen.net> Message-ID: <9229fb14-1c3f-8db6-27b5-e93799f55410@alexhackney.com> I actually got this to work this morning finally. The problem was on my auth server. I see the source auth hook being sent a lot, is there anyway to get the current metadata in that hook? Ideally, every time the source is updated, I'd like to get a hook so I can track the songs that are being played. Alternatively, the only way I can see doing it, is to make a get request every X seconds and watch for the song to change. Alex On 11/7/2018 9:38 AM, Philipp Schafft wrote: > Good afternoon, > > On Wed, 2018-11-07 at 08:08 -0500, Alex Hackney wrote: >> When I stream with winamp, it appears to ask for a username and password >> Everytime. If I just set the return to true no matter what, will it prevent >> the client from asking for a password? > This sounds like there is a configuration problem. Icecast by itself > does not send a 401 without a negative reply from the server (or a > backend failure). > > Maybe you can share your block (with passwords removed (if any)) > with us? > > Please also check your error.log for any problems. Related lines should > include "auth" somewhere in them. > > With best regards, > > >> On Sun, Nov 4, 2018, 06:57 Thomas B. R?cker > >>> >>> On 11/02/2018 11:41 PM, Alex Hackney wrote: >>>> I am looking for a way that I can use to send a hook to my api when >>>> particular things happen. >>>> >>>> For instance, i need to know when listeners or sources connect or >>>> disconnect and when song meta data changes on a stream. >>>> >>>> I see this data on the log and can write a script to do it by >>>> monitoring the log but does icecast have a better way? >>>> >>>> Almost looks like the auth block could do it but I don't want to >>>> prompt listeners for a login. >>>> >>> That's actually how you do it. You use the URL-auth backend and always >>> return positive authentication. >>> >>> Please make sure that you are running version 2.4.4 though. Older >>> versions have a security issue in the URL-auth code! > > > > _______________________________________________ > 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 Fri Nov 9 09:53:44 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Fri, 09 Nov 2018 09:53:44 +0000 Subject: [Icecast] Custom Hooks In-Reply-To: <9229fb14-1c3f-8db6-27b5-e93799f55410@alexhackney.com> References: <1541601504.1925.328.camel@de.loewenfelsen.net> <9229fb14-1c3f-8db6-27b5-e93799f55410@alexhackney.com> Message-ID: <1541757224.1925.339.camel@de.loewenfelsen.net> Good morning, On Thu, 2018-11-08 at 12:45 -0500, Alex Hackney wrote: > I actually got this to work this morning finally. The problem was on my > auth server. Perfect. :) > I see the source auth hook being sent a lot, is there anyway to get the > current metadata in that hook? No. The auth happens long before the client is attached to any source. In fact in Icecast 2.5.x the auth backend can even redirect the client to other resources. > Ideally, every time the source is updated, I'd like to get a hook so I > can track the songs that are being played. Alternatively, the only way I > can see doing it, is to make a get request every X seconds and watch for > the song to change. There currently isn't one. For 2.5.x there already is a ticket[0] for that. What you can do is polling the status XML. You can also use the STATS interface[1]. Also there is the playlist log. You can watch and follow that file to see when updates are made. With best regards, [0] https://gitlab.xiph.org/xiph/icecast-server/issues/2189 [1] Try it with: wget -qO - --method=STATS http://admin:hackme at icecast.example.org:8000/ -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephon: +49.3535 490 17 92 L?wenfelsen UG (haftungsbeschr?nkt) Registration number: Bickinger Stra?e 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From jake at jakebriggs.com Fri Nov 9 09:56:04 2018 From: jake at jakebriggs.com (Jake) Date: Fri, 09 Nov 2018 22:56:04 +1300 Subject: [Icecast] Custom Hooks In-Reply-To: <1541757224.1925.339.camel@de.loewenfelsen.net> References: <1541601504.1925.328.camel@de.loewenfelsen.net> <9229fb14-1c3f-8db6-27b5-e93799f55410@alexhackney.com> <1541757224.1925.339.camel@de.loewenfelsen.net> Message-ID: Couldn't you also just have a client stream locally from icecast that can do things on metadata change? I mean it's a bit icky but it'd work. ---- Philipp Schafft wrote ---- >Good morning, > >On Thu, 2018-11-08 at 12:45 -0500, Alex Hackney wrote: >> I actually got this to work this morning finally. The problem was on my >> auth server. > >Perfect. :) > > >> I see the source auth hook being sent a lot, is there anyway to get the >> current metadata in that hook? > >No. The auth happens long before the client is attached to any source. >In fact in Icecast 2.5.x the auth backend can even redirect the client >to other resources. > > >> Ideally, every time the source is updated, I'd like to get a hook so I >> can track the songs that are being played. Alternatively, the only way I >> can see doing it, is to make a get request every X seconds and watch for >> the song to change. > >There currently isn't one. For 2.5.x there already is a ticket[0] for >that. > >What you can do is polling the status XML. You can also use the STATS >interface[1]. Also there is the playlist log. You can watch and follow >that file to see when updates are made. > >With best regards, > > > >[0] https://gitlab.xiph.org/xiph/icecast-server/issues/2189 >[1] Try it with: wget -qO - --method=STATS >http://admin:hackme at icecast.example.org:8000/ > > >-- >Philipp Schafft (CEO/Gesch?ftsf?hrer) >Telephon: +49.3535 490 17 92 > >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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From phschafft at de.loewenfelsen.net Fri Nov 9 10:09:53 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Fri, 09 Nov 2018 10:09:53 +0000 Subject: [Icecast] Custom Hooks In-Reply-To: References: <1541601504.1925.328.camel@de.loewenfelsen.net> <9229fb14-1c3f-8db6-27b5-e93799f55410@alexhackney.com> <1541757224.1925.339.camel@de.loewenfelsen.net> Message-ID: <1541758193.1925.341.camel@de.loewenfelsen.net> Good morning, On Fri, 2018-11-09 at 22:56 +1300, Jake wrote: > Couldn't you also just have a client stream locally from icecast that > can do things on metadata change? I mean it's a bit icky but it'd > work. If you know any player that can do things on metadata change and works for the given setup: sure. Why not? The main downside of this is that it may require a little bit more setup and requires more resources as the player will likely decode the actual stream as well. With best regards, > ---- Philipp Schafft wrote ---- > > >Good morning, > > > >On Thu, 2018-11-08 at 12:45 -0500, Alex Hackney wrote: > >> I actually got this to work this morning finally. The problem was on my > >> auth server. > > > >Perfect. :) > > > > > >> I see the source auth hook being sent a lot, is there anyway to get the > >> current metadata in that hook? > > > >No. The auth happens long before the client is attached to any source. > >In fact in Icecast 2.5.x the auth backend can even redirect the client > >to other resources. > > > > > >> Ideally, every time the source is updated, I'd like to get a hook so I > >> can track the songs that are being played. Alternatively, the only way I > >> can see doing it, is to make a get request every X seconds and watch for > >> the song to change. > > > >There currently isn't one. For 2.5.x there already is a ticket[0] for > >that. > > > >What you can do is polling the status XML. You can also use the STATS > >interface[1]. Also there is the playlist log. You can watch and follow > >that file to see when updates are made. > > > >With best regards, > > > > > > > >[0] https://gitlab.xiph.org/xiph/icecast-server/issues/2189 > >[1] Try it with: wget -qO - --method=STATS > >http://admin:hackme at icecast.example.org:8000/ > > > > > >-- > >Philipp Schafft (CEO/Gesch?ftsf?hrer) > >Telephon: +49.3535 490 17 92 > > > >L?wenfelsen UG (haftungsbeschr?nkt) Registration number: > >Bickinger Stra?e 21 HRB 12308 CB > >04916 Herzberg (Elster) VATIN/USt-ID: > >Germany DE305133015 -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephon: +49.3535 490 17 92 L?wenfelsen UG (haftungsbeschr?nkt) Registration number: Bickinger Stra?e 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From jake at jakebriggs.com Fri Nov 9 10:53:48 2018 From: jake at jakebriggs.com (jake) Date: Fri, 09 Nov 2018 23:53:48 +1300 Subject: [Icecast] Custom Hooks In-Reply-To: <1541758193.1925.341.camel@de.loewenfelsen.net> References: <1541601504.1925.328.camel@de.loewenfelsen.net> <9229fb14-1c3f-8db6-27b5-e93799f55410@alexhackney.com> <1541757224.1925.339.camel@de.loewenfelsen.net> <1541758193.1925.341.camel@de.loewenfelsen.net> Message-ID: Yeah it is a tad gross but here is my first (and probably only) attempt: ---------------- 8< ---------------- #!/bin/bash pipe=/tmp/testpipe trap "rm -f $pipe" EXIT if [[ ! -p $pipe ]]; then mkfifo $pipe fi mplayer -slave -playlist "http://my.icecast.stream/music" > /tmp/testpipe 2> /dev/null & while true do if read line <$pipe; then echo $line /bin/dothing "$line" fi done echo "Reader exiting" ---------------- 8< ---------------- Basically use mplayer to stream, redirecting its output to a named pipe. Then, read line on the pipe for ever, once a line comes in echo it and call /bin/dothing "$line", then go back to read line. The script is basic and would need a little work to ignore all lines that don't start with "ICY Info: " since the output is something like: ---------------- 8< ---------------- Resolving my.icecast.stream for AF_INET6... Resolving my.icecast.stream for AF_INET... Connecting to server my.icecast.stream: 80... Name : name Genre : Misc Website: http://savonet.sf.net Public : yes Cache size set to 320 KBytes ICY Info: StreamTitle='Regurgitator - ! (The Song Formerly Known As)'; ICY Info: StreamTitle='Queens of the Stone Age - Walkin' On The Sidewalks'; ICY Info: StreamTitle='foo - bar'; ICY Info: StreamTitle='Another Metadata Change'; ... ... ... ... ---------------- 8< ---------------- but yeah something like this might work fine until a better solution comes along. Jake ~ On 2018-11-09 23:09, Philipp Schafft wrote: > Good morning, > > On Fri, 2018-11-09 at 22:56 +1300, Jake wrote: >> Couldn't you also just have a client stream locally from icecast that >> can do things on metadata change? I mean it's a bit icky but it'd >> work. > > If you know any player that can do things on metadata change and works > for the given setup: sure. Why not? > > The main downside of this is that it may require a little bit more > setup > and requires more resources as the player will likely decode the actual > stream as well. > > With best regards, > >> ---- Philipp Schafft wrote ---- >> >> >Good morning, >> > >> >On Thu, 2018-11-08 at 12:45 -0500, Alex Hackney wrote: >> >> I actually got this to work this morning finally. The problem was on my >> >> auth server. >> > >> >Perfect. :) >> > >> > >> >> I see the source auth hook being sent a lot, is there anyway to get the >> >> current metadata in that hook? >> > >> >No. The auth happens long before the client is attached to any source. >> >In fact in Icecast 2.5.x the auth backend can even redirect the client >> >to other resources. >> > >> > >> >> Ideally, every time the source is updated, I'd like to get a hook so I >> >> can track the songs that are being played. Alternatively, the only way I >> >> can see doing it, is to make a get request every X seconds and watch for >> >> the song to change. >> > >> >There currently isn't one. For 2.5.x there already is a ticket[0] for >> >that. >> > >> >What you can do is polling the status XML. You can also use the STATS >> >interface[1]. Also there is the playlist log. You can watch and follow >> >that file to see when updates are made. >> > >> >With best regards, >> > >> > >> > >> >[0] https://gitlab.xiph.org/xiph/icecast-server/issues/2189 >> >[1] Try it with: wget -qO - --method=STATS >> >http://admin:hackme at icecast.example.org:8000/ >> > >> > >> >-- >> >Philipp Schafft (CEO/Gesch?ftsf?hrer) >> >Telephon: +49.3535 490 17 92 >> > >> >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 phschafft at de.loewenfelsen.net Fri Nov 9 11:10:22 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Fri, 09 Nov 2018 11:10:22 +0000 Subject: [Icecast] Micro Guide to Understanding Icecast 2.5.x authentication (For Icecast 2.5 beta 3) Message-ID: <1541761822.1925.393.camel@de.loewenfelsen.net> Good morning, as there has been some confusion I thought it might be best to write some little "Micro Guide" for Icecast 2.5.x's authentication subsystem. This E-Mail refers to not yet released version 2.5 beta 3 (to be released soon). !!! /!\ !!! If you run Icecast 2.4.x (stable) this E-Mail is not relevant to you! !!! /!\ !!! Overview Icecast 2.5.x changed the authentication system very much since Icecast 2.4.x. But good news first: Icecast 2.5.x can read Icecast 2.4.x config files and will behave correctly. The new system works by a set of rules. Rules are tried from top to bottom. The first one that matches wins. When a rule matches a set of access control parameters are set. Rules can be defined by (and tried in this order): * listen sockets (), * normal mounts (), * default mounts (), * the global list (). Each of those blocks can contain a subtag. (Note: It must not set a type="", otherwise it will be interpreted as Icecast 2.4.x config). Each such can contain a number of tags. Each tag defines a rule. A tag can include