From fredg at paravelsystems.com Sat Dec 1 23:13:46 2018 From: fredg at paravelsystems.com (Fred Gleason) Date: Sat, 1 Dec 2018 18:13:46 -0500 Subject: [Icecast] Character encodings in ICY metadata Message-ID: <3F5CFCA4-F109-4897-856A-63DFC4160307@paravelsystems.com> Greetings Icecast masters! Does anyone know what the supported character encoding(s) are for strings in ICY metadata? The closest I?ve been able to get via a Google search is this thread: http://forums.winamp.com/showthread.php?t=208096&highlight=handle+unicode+characters%3F Which would certainly seem to imply that UTF-8 is off the table. (Or is it just a Winamp limitation?) Is there an actual server-side standard? Any light shed would be greatly appreciated. Cheers! |----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | The nice thing about standards is that there are so many of them to | | choose from. | | -- Andrew S. Tanenbaum | |----------------------------------------------------------------------| -------------- next part -------------- An HTML attachment was scrubbed... URL: From epirat07 at gmail.com Sun Dec 2 00:10:02 2018 From: epirat07 at gmail.com (Marvin Scholz) Date: Sun, 02 Dec 2018 01:10:02 +0100 Subject: [Icecast] Character encodings in ICY metadata In-Reply-To: <3F5CFCA4-F109-4897-856A-63DFC4160307@paravelsystems.com> References: <3F5CFCA4-F109-4897-856A-63DFC4160307@paravelsystems.com> Message-ID: <41271533-9107-4745-89D5-FE43448A5CCE@gmail.com> On 2 Dec 2018, at 0:13, Fred Gleason wrote: > Greetings Icecast masters! > > > Does anyone know what the supported character encoding(s) are for > strings in ICY metadata? The closest I?ve been able to get via a > Google search is this thread: > > http://forums.winamp.com/showthread.php?t=208096&highlight=handle+unicode+characters%3F > > > Which would certainly seem to imply that UTF-8 is off the table. (Or > is it just a Winamp limitation?) Is there an actual server-side > standard? Not really, I've seen servers and players do all sorts of encodings. > > Any light shed would be greatly appreciated. > > Cheers! > > > |----------------------------------------------------------------------| > | Frederick F. Gleason, Jr. | Chief Developer > | > | | Paravel Systems > | > |----------------------------------------------------------------------| > | The nice thing about standards is that there are so many of them to > | > | choose from. > | > | -- Andrew S. Tanenbaum > | > |----------------------------------------------------------------------|_______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From greg at indexcom.com Sun Dec 2 00:20:23 2018 From: greg at indexcom.com (Greg Ogonowski) Date: Sat, 1 Dec 2018 16:20:23 -0800 Subject: [Icecast] Character encodings in ICY metadata In-Reply-To: <3F5CFCA4-F109-4897-856A-63DFC4160307@paravelsystems.com> References: <3F5CFCA4-F109-4897-856A-63DFC4160307@paravelsystems.com> Message-ID: <001701d489d4$d183b9d0$748b2d70$@indexcom.com> UTF-8 is now the universal standard. It supports ALL character sets. /greg. StreamS HiFi From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Fred Gleason Sent: Saturday, December 01, 2018 15:14 To: Icecast streaming server user discussions Subject: [Icecast] Character encodings in ICY metadata Available Attachments * Untitled attachment 00015.txt Greetings Icecast masters! Does anyone know what the supported character encoding(s) are for strings in ICY metadata? The closest I?ve been able to get via a Google search is this thread: http://forums.winamp.com/showthread.php?t=208096 &highlight=handle+unicode+characters%3F Which would certainly seem to imply that UTF-8 is off the table. (Or is it just a Winamp limitation?) Is there an actual server-side standard? Any light shed would be greatly appreciated. Cheers! |----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | The nice thing about standards is that there are so many of them to | | choose from. | | -- Andrew S. Tanenbaum | |----------------------------------------------------------------------| -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredg at paravelsystems.com Sun Dec 2 01:08:33 2018 From: fredg at paravelsystems.com (Fred Gleason) Date: Sat, 1 Dec 2018 20:08:33 -0500 Subject: [Icecast] Character encodings in ICY metadata In-Reply-To: <001701d489d4$d183b9d0$748b2d70$@indexcom.com> References: <3F5CFCA4-F109-4897-856A-63DFC4160307@paravelsystems.com> <001701d489d4$d183b9d0$748b2d70$@indexcom.com> Message-ID: On Dec 1, 2018, at 19:20, Greg Ogonowski wrote: > UTF-8 is now the universal standard. > It supports ALL character sets. Cool. That makes it straightforward. Thank you. Cheers! |----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | There are two ways of constructing a software design. One is to | | make it so simple that there are obviously no deficiencies; the | | other is to make it so complicated that there are no obvious | | deficiencies. The first method is far more difficult. | | --C.A.R Hoare | |----------------------------------------------------------------------| -------------- next part -------------- An HTML attachment was scrubbed... URL: From phschafft at de.loewenfelsen.net Mon Dec 3 08:50:07 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Mon, 03 Dec 2018 08:50:07 +0000 Subject: [Icecast] Character encodings in ICY metadata In-Reply-To: <001701d489d4$d183b9d0$748b2d70$@indexcom.com> References: <3F5CFCA4-F109-4897-856A-63DFC4160307@paravelsystems.com> <001701d489d4$d183b9d0$748b2d70$@indexcom.com> Message-ID: <1543827007.1923.64.camel@de.loewenfelsen.net> Good morning, On Sat, 2018-12-01 at 16:20 -0800, Greg Ogonowski wrote: > UTF-8 is now the universal standard. (ICY context:) Expect if you are in Asia. Or in central Europe. Or maybe in Africa. I'm not aware of servers on the poles, maybe they use..., ... > It supports ALL character sets. As long as "ALL" is defined as what English people need plus all emoji in all skin colours but green. There are still a lot characters not included even if the set they contain to is in the list. While UTF-8 is most likely the way you want to go, it is by no means universal. The truth is that ICY is just a broken protocol that does not give you any way to define what charset you use. So you need to guess anyway. Some software guesses by detecting special characters in the strings, some by using a randomly chosen fixed charset (yes, just using UTF-8 is randomly chosen). ICY streams are also changing charset between updates at will. Generally speaking I would strongly recommend to migrate away from it. 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 greg at indexcom.com Mon Dec 3 09:38:08 2018 From: greg at indexcom.com (Greg Ogonowski) Date: Mon, 3 Dec 2018 01:38:08 -0800 Subject: [Icecast] Character encodings in ICY metadata In-Reply-To: <1543827007.1923.64.camel@de.loewenfelsen.net> References: <1543827007.1923.64.camel@de.loewenfelsen.net> Message-ID: <001701d48aeb$e65980c0$b30c8240$@indexcom.com> UTF-8 handles ALL character sets. That?s the whole idea of Unicode. We have encoder users all over the world using UTF-8. Handles all Asian languages with no problem, including Burmese which is a more recent addition to the current Unicode version due to additional complications. Requires Operating Systems with the latest Unicode version. Here is an HLS stream with metadata done right: https://db2.indexcom.com/playertest/05_diag/ Note Extensible Metadata Fields have been set up with multiple languages, and they are all sent at once. In order for this to work properly, the entire metadata path from start to finish is required to be UTF-8 Unicode. Any modern software is. /greg. StreamS HiFi Radio From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Philipp Schafft Sent: Monday, December 03, 2018 00:50 To: Icecast streaming server user discussions Subject: Re: [Icecast] Character encodings in ICY metadata Available Attachments * signature.asc * Untitled attachment 00016.txt Good morning, On Sat, 2018-12-01 at 16:20 -0800, Greg Ogonowski wrote: > UTF-8 is now the universal standard. (ICY context:) Expect if you are in Asia. Or in central Europe. Or maybe in Africa. I'm not aware of servers on the poles, maybe they use..., ... > It supports ALL character sets. As long as "ALL" is defined as what English people need plus all emoji in all skin colours but green. There are still a lot characters not included even if the set they contain to is in the list. While UTF-8 is most likely the way you want to go, it is by no means universal. The truth is that ICY is just a broken protocol that does not give you any way to define what charset you use. So you need to guess anyway. Some software guesses by detecting special characters in the strings, some by using a randomly chosen fixed charset (yes, just using UTF-8 is randomly chosen). ICY streams are also changing charset between updates at will. Generally speaking I would strongly recommend to migrate away from it. 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 -------------- An HTML attachment was scrubbed... URL: From fredg at paravelsystems.com Mon Dec 3 12:13:24 2018 From: fredg at paravelsystems.com (Fred Gleason) Date: Mon, 3 Dec 2018 07:13:24 -0500 Subject: [Icecast] Character encodings in ICY metadata In-Reply-To: <001701d48aeb$e65980c0$b30c8240$@indexcom.com> References: <1543827007.1923.64.camel@de.loewenfelsen.net> <001701d48aeb$e65980c0$b30c8240$@indexcom.com> Message-ID: <085919FB-37B8-4519-946C-D98B1CDB57E0@paravelsystems.com> On Dec 3, 2018, at 04:38, Greg Ogonowski wrote: > Here is an HLS stream with metadata done right: > https://db2.indexcom.com/playertest/05_diag/ Nice (although rather out of scope for list devoted to Icecast discussion). > Note Extensible Metadata Fields have been set up with multiple languages, and they are all sent at once. > In order for this to work properly, the entire metadata path from start to finish is required to be UTF-8 Unicode. Any modern software is. I see you?re doing that by layering it onto the HTML presentation, rather than including it in the m3u8 data. Interesting (albeit rather fragile methinks)? Cheers! |----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | Opportunity is missed by most people because it is dressed in | | overalls and looks like work. | | -- Thomas Edison | |----------------------------------------------------------------------| -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvandop at xs4all.nl Wed Dec 5 10:29:28 2018 From: mvandop at xs4all.nl (Michel van Dop) Date: Wed, 05 Dec 2018 11:29:28 +0100 Subject: [Icecast] https stream play 1 second and stop Message-ID: <954ee3dc9b2c530f262c877d8e236c92@xs4all.nl> Hi, We have sometimes a problems with playing in https the stream starts playing and stops in html5 or direct in the browser after a second. If we use the same stream on http, there is no problem. I can not find anything in the error log. We use Icecast 2.4.3. Is this problem solve in 2.4.4? Best regards, Michel -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From phschafft at de.loewenfelsen.net Wed Dec 5 11:10:17 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Wed, 05 Dec 2018 11:10:17 +0000 Subject: [Icecast] https stream play 1 second and stop In-Reply-To: <954ee3dc9b2c530f262c877d8e236c92@xs4all.nl> References: <954ee3dc9b2c530f262c877d8e236c92@xs4all.nl> Message-ID: <1544008217.1923.109.camel@de.loewenfelsen.net> Good morning, On Wed, 2018-12-05 at 11:29 +0100, Michel van Dop wrote: > Hi, > > We have sometimes a problems with playing in https the stream starts > playing and stops in html5 or direct in the browser after a second. > If we use the same stream on http, there is no problem. I can not find > anything in the error log. > > We use Icecast 2.4.3. Is this problem solve in 2.4.4? There is no such bug known to us in Icecast. However: There is a bug in some OpenSSL versions that cause this behaviour. Which OpenSSL version do you use? Please also note that 2.4.4 include a very important security fix for URL Auth [0]. So upgrade to Icecast 2.4.4 is generally recommended. With best regards, [0] https://icecast.org/news/icecast-release_2_4_4/ -- 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 mvandop at xs4all.nl Wed Dec 5 12:02:18 2018 From: mvandop at xs4all.nl (Michel van Dop) Date: Wed, 05 Dec 2018 13:02:18 +0100 Subject: [Icecast] https stream play 1 second and stop In-Reply-To: <1544008217.1923.109.camel@de.loewenfelsen.net> References: <954ee3dc9b2c530f262c877d8e236c92@xs4all.nl> <1544008217.1923.109.camel@de.loewenfelsen.net> Message-ID: <5d27e53b831c7cd1962f38b0b9b05b9b@xs4all.nl> Hi Philipp, We use OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS Linux release 7.5.1804 (Core) When we restart the Icecast stream the problem is gone. Best regards, Michel Philipp Schafft schreef op 2018-12-05 12:10: > Good morning, > > On Wed, 2018-12-05 at 11:29 +0100, Michel van Dop wrote: > >> Hi, >> >> We have sometimes a problems with playing in https the stream starts >> playing and stops in html5 or direct in the browser after a second. >> If we use the same stream on http, there is no problem. I can not find >> anything in the error log. >> >> We use Icecast 2.4.3. Is this problem solve in 2.4.4? > > There is no such bug known to us in Icecast. However: > There is a bug in some OpenSSL versions that cause this behaviour. > > Which OpenSSL version do you use? > > Please also note that 2.4.4 include a very important security fix for > URL Auth [0 [1]]. So upgrade to Icecast 2.4.4 is generally recommended. > > With best regards, > > [0] https://icecast.org/news/icecast-release_2_4_4/ > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -- Links: ------ [1] https://icecast.org/news/icecast-release_2_4_4/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From phschafft at de.loewenfelsen.net Wed Dec 5 13:09:07 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Wed, 05 Dec 2018 13:09:07 +0000 Subject: [Icecast] https stream play 1 second and stop In-Reply-To: <5d27e53b831c7cd1962f38b0b9b05b9b@xs4all.nl> References: <954ee3dc9b2c530f262c877d8e236c92@xs4all.nl> <1544008217.1923.109.camel@de.loewenfelsen.net> <5d27e53b831c7cd1962f38b0b9b05b9b@xs4all.nl> Message-ID: <1544015347.1923.110.camel@de.loewenfelsen.net> Good afternoon, On Wed, 2018-12-05 at 13:02 +0100, Michel van Dop wrote: > Hi Philipp, > > We use OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS Linux release 7.5.1804 > (Core) > > When we restart the Icecast stream the problem is gone. The problem is gone when you restart the STREAM or when you restart Icecast? Do you have an URL to such a stream for me? With best regards, > Philipp Schafft schreef op 2018-12-05 12:10: > > > Good morning, > > > > On Wed, 2018-12-05 at 11:29 +0100, Michel van Dop wrote: > > > >> Hi, > >> > >> We have sometimes a problems with playing in https the stream starts > >> playing and stops in html5 or direct in the browser after a second. > >> If we use the same stream on http, there is no problem. I can not find > >> anything in the error log. > >> > >> We use Icecast 2.4.3. Is this problem solve in 2.4.4? > > > > There is no such bug known to us in Icecast. However: > > There is a bug in some OpenSSL versions that cause this behaviour. > > > > Which OpenSSL version do you use? > > > > Please also note that 2.4.4 include a very important security fix for > > URL Auth [0 [1]]. So upgrade to Icecast 2.4.4 is generally recommended. > > > > With best regards, > > > > [0] https://icecast.org/news/icecast-release_2_4_4/ -- 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 thomas at ruecker.fi Wed Dec 5 14:38:19 2018 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B=2e_R=c3=bccker?=) Date: Wed, 5 Dec 2018 14:38:19 +0000 Subject: [Icecast] https stream play 1 second and stop In-Reply-To: <1544015347.1923.110.camel@de.loewenfelsen.net> References: <954ee3dc9b2c530f262c877d8e236c92@xs4all.nl> <1544008217.1923.109.camel@de.loewenfelsen.net> <5d27e53b831c7cd1962f38b0b9b05b9b@xs4all.nl> <1544015347.1923.110.camel@de.loewenfelsen.net> Message-ID: <95a3ab5a-03b8-2fb4-6d77-df9cdc73427b@ruecker.fi> Hi, On 12/5/18 1:09 PM, Philipp Schafft wrote: > Good afternoon, > > On Wed, 2018-12-05 at 13:02 +0100, Michel van Dop wrote: >> Hi Philipp, >> >> We use OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS Linux release 7.5.1804 >> (Core) >> >> When we restart the Icecast stream the problem is gone. This sounds very similar to this: https://stackoverflow.com/q/53577121/2648865 > The problem is gone when you restart the STREAM or when you restart > Icecast? > > Do you have an URL to such a stream for me? > > With best regards, > > >> Philipp Schafft schreef op 2018-12-05 12:10: >> >>> Good morning, >>> >>> On Wed, 2018-12-05 at 11:29 +0100, Michel van Dop wrote: >>> >>>> Hi, >>>> >>>> We have sometimes a problems with playing in https the stream starts >>>> playing and stops in html5 or direct in the browser after a second. >>>> If we use the same stream on http, there is no problem. I can not find >>>> anything in the error log. >>>> >>>> We use Icecast 2.4.3. Is this problem solve in 2.4.4? >>> There is no such bug known to us in Icecast. However: >>> There is a bug in some OpenSSL versions that cause this behaviour. >>> >>> Which OpenSSL version do you use? >>> >>> Please also note that 2.4.4 include a very important security fix for >>> URL Auth [0 [1]]. So upgrade to Icecast 2.4.4 is generally recommended. >>> >>> With best regards, >>> >>> [0] https://icecast.org/news/icecast-release_2_4_4/ > Cheers, 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 GDearth at olivet.edu Wed Dec 5 13:20:00 2018 From: GDearth at olivet.edu (Gary Dearth) Date: Wed, 5 Dec 2018 13:20:00 +0000 Subject: [Icecast] https stream play 1 second and stop In-Reply-To: <1544015347.1923.110.camel@de.loewenfelsen.net> References: <954ee3dc9b2c530f262c877d8e236c92@xs4all.nl> <1544008217.1923.109.camel@de.loewenfelsen.net> <5d27e53b831c7cd1962f38b0b9b05b9b@xs4all.nl> <1544015347.1923.110.camel@de.loewenfelsen.net> Message-ID: I have the same issue occur on a windows server 2008 running 2.4.3 and recently upgraded to 2.4.4 I don?t know what open ssl was packaged with it. It seems to run fine for a week or two and then all of a sudden it starts this same issue of playing one second and then stopping. Restart the service and it works fine for another week or two. But only an issue on https, the http streams are fine. Been dealing with this since beginning of year when we created the https streams for alexa use. Got my distro from the icecast.org repository. Gary D. -----Original Message----- From: Icecast On Behalf Of Philipp Schafft Sent: Wednesday, December 05, 2018 7:09 AM To: Icecast streaming server user discussions Subject: Re: [Icecast] https stream play 1 second and stop Good afternoon, On Wed, 2018-12-05 at 13:02 +0100, Michel van Dop wrote: > Hi Philipp, > > We use OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS Linux release > 7.5.1804 > (Core) > > When we restart the Icecast stream the problem is gone. The problem is gone when you restart the STREAM or when you restart Icecast? Do you have an URL to such a stream for me? With best regards, > Philipp Schafft schreef op 2018-12-05 12:10: > > > Good morning, > > > > On Wed, 2018-12-05 at 11:29 +0100, Michel van Dop wrote: > > > >> Hi, > >> > >> We have sometimes a problems with playing in https the stream > >> starts playing and stops in html5 or direct in the browser after a second. > >> If we use the same stream on http, there is no problem. I can not > >> find anything in the error log. > >> > >> We use Icecast 2.4.3. Is this problem solve in 2.4.4? > > > > There is no such bug known to us in Icecast. However: > > There is a bug in some OpenSSL versions that cause this behaviour. > > > > Which OpenSSL version do you use? > > > > Please also note that 2.4.4 include a very important security fix > > for URL Auth [0 [1]]. So upgrade to Icecast 2.4.4 is generally recommended. > > > > With best regards, > > > > [0] https://icecast.org/news/icecast-release_2_4_4/ -- 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 From mvandop at xs4all.nl Thu Dec 6 08:59:10 2018 From: mvandop at xs4all.nl (Michel van Dop) Date: Thu, 06 Dec 2018 09:59:10 +0100 Subject: [Icecast] https stream play 1 second and stop In-Reply-To: References: <954ee3dc9b2c530f262c877d8e236c92@xs4all.nl> <1544008217.1923.109.camel@de.loewenfelsen.net> <5d27e53b831c7cd1962f38b0b9b05b9b@xs4all.nl> <1544015347.1923.110.camel@de.loewenfelsen.net> Message-ID: <8ea43b850a889b15efdc322dde4fdcb5@xs4all.nl> Hi, What strikes me is that the problem is with a mp3 stream. We use in the same icecast stream FLAC and opus and the have not this problem. Gary do you have this problem only on a mp3 stream? I use ProppFrexx onair Pro encoders for mp3. And i see this problem on Sam Broadcaster Pro 2018.x (lame encoders). I must restart Icecast and it works fine for another week or two (same). I try to stop en start the encoder in ProppFrexx but i do not solve the problem. I send Philipp personally a stream url where it goes wrong now (not restarted). Best regards, Michel Gary Dearth schreef op 2018-12-05 14:20: > I have the same issue occur on a windows server 2008 running 2.4.3 and recently upgraded to 2.4.4 > I don't know what open ssl was packaged with it. It seems to run fine for a week or two and then all of a sudden it starts this same issue of playing one second and then stopping. Restart the service and it works fine for another week or two. But only an issue on https, the http streams are fine. Been dealing with this since beginning of year when we created the https streams for alexa use. Got my distro from the icecast.org repository. > > Gary D. > > -----Original Message----- > From: Icecast On Behalf Of Philipp Schafft > Sent: Wednesday, December 05, 2018 7:09 AM > To: Icecast streaming server user discussions > Subject: Re: [Icecast] https stream play 1 second and stop > > Good afternoon, > > On Wed, 2018-12-05 at 13:02 +0100, Michel van Dop wrote: > >> Hi Philipp, >> >> We use OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS Linux release >> 7.5.1804 >> (Core) >> >> When we restart the Icecast stream the problem is gone. > > The problem is gone when you restart the STREAM or when you restart Icecast? > > Do you have an URL to such a stream for me? > > With best regards, > > Philipp Schafft schreef op 2018-12-05 12:10: > > Good morning, > > On Wed, 2018-12-05 at 11:29 +0100, Michel van Dop wrote: > > Hi, > > We have sometimes a problems with playing in https the stream > starts playing and stops in html5 or direct in the browser after a second. > If we use the same stream on http, there is no problem. I can not > find anything in the error log. > > We use Icecast 2.4.3. Is this problem solve in 2.4.4? > There is no such bug known to us in Icecast. However: > There is a bug in some OpenSSL versions that cause this behaviour. > > Which OpenSSL version do you use? > > Please also note that 2.4.4 include a very important security fix > for URL Auth [0 [1]]. So upgrade to Icecast 2.4.4 is generally recommended. > > With best regards, > > [0] https://icecast.org/news/icecast-release_2_4_4/ -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From GDearth at olivet.edu Thu Dec 6 13:50:42 2018 From: GDearth at olivet.edu (Gary Dearth) Date: Thu, 6 Dec 2018 13:50:42 +0000 Subject: [Icecast] https stream play 1 second and stop In-Reply-To: <8ea43b850a889b15efdc322dde4fdcb5@xs4all.nl> References: <954ee3dc9b2c530f262c877d8e236c92@xs4all.nl> <1544008217.1923.109.camel@de.loewenfelsen.net> <5d27e53b831c7cd1962f38b0b9b05b9b@xs4all.nl> <1544015347.1923.110.camel@de.loewenfelsen.net> <8ea43b850a889b15efdc322dde4fdcb5@xs4all.nl> Message-ID: Thanks for your response Michel. I encode with Omnia AX/E Software so that it can be processed a bit and it has built in MP3 Encoders. I believe it is happening to all my streams, but I only use the mp3 codec. Was encouraged to hear that I wasn?t the only one having an issue and look forward to some trouble shooting thoughts. I do not build my own packages so whatever OpenSSL version is in the win32 release on icecast.org is what I have used. Thanks Gary D From: Michel van Dop Sent: Thursday, December 06, 2018 2:59 AM To: Icecast streaming server user discussions Cc: Gary Dearth Subject: Re: [Icecast] https stream play 1 second and stop Hi, What strikes me is that the problem is with a mp3 stream. We use in the same icecast stream FLAC and opus and the have not this problem. Gary do you have this problem only on a mp3 stream? I use ProppFrexx onair Pro encoders for mp3. And i see this problem on Sam Broadcaster Pro 2018.x (lame encoders). I must restart Icecast and it works fine for another week or two (same). I try to stop en start the encoder in ProppFrexx but i do not solve the problem. I send Philipp personally a stream url where it goes wrong now (not restarted). Best regards, Michel Gary Dearth schreef op 2018-12-05 14:20: I have the same issue occur on a windows server 2008 running 2.4.3 and recently upgraded to 2.4.4 I don't know what open ssl was packaged with it. It seems to run fine for a week or two and then all of a sudden it starts this same issue of playing one second and then stopping. Restart the service and it works fine for another week or two. But only an issue on https, the http streams are fine. Been dealing with this since beginning of year when we created the https streams for alexa use. Got my distro from the icecast.org repository. Gary D. -----Original Message----- From: Icecast > On Behalf Of Philipp Schafft Sent: Wednesday, December 05, 2018 7:09 AM To: Icecast streaming server user discussions > Subject: Re: [Icecast] https stream play 1 second and stop Good afternoon, On Wed, 2018-12-05 at 13:02 +0100, Michel van Dop wrote: Hi Philipp, We use OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS Linux release 7.5.1804 (Core) When we restart the Icecast stream the problem is gone. The problem is gone when you restart the STREAM or when you restart Icecast? Do you have an URL to such a stream for me? With best regards, Philipp Schafft schreef op 2018-12-05 12:10: Good morning, On Wed, 2018-12-05 at 11:29 +0100, Michel van Dop wrote: Hi, We have sometimes a problems with playing in https the stream starts playing and stops in html5 or direct in the browser after a second. If we use the same stream on http, there is no problem. I can not find anything in the error log. We use Icecast 2.4.3. Is this problem solve in 2.4.4? There is no such bug known to us in Icecast. However: There is a bug in some OpenSSL versions that cause this behaviour. Which OpenSSL version do you use? Please also note that 2.4.4 include a very important security fix for URL Auth [0 [1]]. So upgrade to Icecast 2.4.4 is generally recommended. With best regards, [0] https://icecast.org/news/icecast-release_2_4_4/ -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvandop at xs4all.nl Thu Dec 6 20:32:41 2018 From: mvandop at xs4all.nl (Michel van Dop) Date: Thu, 06 Dec 2018 21:32:41 +0100 Subject: [Icecast] https stream play 1 second and stop In-Reply-To: References: <954ee3dc9b2c530f262c877d8e236c92@xs4all.nl> <1544008217.1923.109.camel@de.loewenfelsen.net> <5d27e53b831c7cd1962f38b0b9b05b9b@xs4all.nl> <1544015347.1923.110.camel@de.loewenfelsen.net> <8ea43b850a889b15efdc322dde4fdcb5@xs4all.nl> Message-ID: Hi Gary, I change the type of encoder for the mountpoint what go wrong from mp3 to opus, but same problem. No mp3 problem. I restart Icecast and it works again. I set the log on (4) debug mode hope i can find something. Best regards, Michel Gary Dearth schreef op 2018-12-06 14:50: > Thanks for your response Michel. I encode with Omnia AX/E Software so that it can be processed a bit and it has built in MP3 Encoders. I believe it is happening to all my streams, but I only use the mp3 codec. Was encouraged to hear that I wasn't the only one having an issue and look forward to some trouble shooting thoughts. I do not build my own packages so whatever OpenSSL version is in the win32 release on icecast.org is what I have used. > > Thanks > > Gary D > > FROM: Michel van Dop > SENT: Thursday, December 06, 2018 2:59 AM > TO: Icecast streaming server user discussions > CC: Gary Dearth > SUBJECT: Re: [Icecast] https stream play 1 second and stop > > Hi, > > What strikes me is that the problem is with a mp3 stream. We use in the same icecast stream FLAC and opus and the have not this problem. > Gary do you have this problem only on a mp3 stream? I use ProppFrexx onair Pro encoders for mp3. > And i see this problem on Sam Broadcaster Pro 2018.x (lame encoders). > > I must restart Icecast and it works fine for another week or two (same). I try to stop en start the encoder in ProppFrexx but i do not solve the problem. > > I send Philipp personally a stream url where it goes wrong now (not restarted). > > Best regards, > Michel > > Gary Dearth schreef op 2018-12-05 14:20: > > I have the same issue occur on a windows server 2008 running 2.4.3 and recently upgraded to 2.4.4 > I don't know what open ssl was packaged with it. It seems to run fine for a week or two and then all of a sudden it starts this same issue of playing one second and then stopping. Restart the service and it works fine for another week or two. But only an issue on https, the http streams are fine. Been dealing with this since beginning of year when we created the https streams for alexa use. Got my distro from the icecast.org repository. > > Gary D. > > -----Original Message----- > From: Icecast On Behalf Of Philipp Schafft > Sent: Wednesday, December 05, 2018 7:09 AM > To: Icecast streaming server user discussions > Subject: Re: [Icecast] https stream play 1 second and stop > > Good afternoon, > > On Wed, 2018-12-05 at 13:02 +0100, Michel van Dop wrote: > > Hi Philipp, > > We use OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS Linux release > 7.5.1804 > (Core) > > When we restart the Icecast stream the problem is gone. > > The problem is gone when you restart the STREAM or when you restart Icecast? > > Do you have an URL to such a stream for me? > > With best regards, > > Philipp Schafft schreef op 2018-12-05 12:10: > > Good morning, > > On Wed, 2018-12-05 at 11:29 +0100, Michel van Dop wrote: > > Hi, > > We have sometimes a problems with playing in https the stream > starts playing and stops in html5 or direct in the browser after a second. > If we use the same stream on http, there is no problem. I can not > find anything in the error log. > > We use Icecast 2.4.3. Is this problem solve in 2.4.4? > > There is no such bug known to us in Icecast. However: > There is a bug in some OpenSSL versions that cause this behaviour. > > Which OpenSSL version do you use? > > Please also note that 2.4.4 include a very important security fix > for URL Auth [0 [1]]. So upgrade to Icecast 2.4.4 is generally recommended. > > With best regards, > > [0] https://icecast.org/news/icecast-release_2_4_4/ [1] -- -- Links: ------ [1] https://icecast.org/news/icecast-release_2_4_4/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvandop at xs4all.nl Fri Dec 7 12:14:12 2018 From: mvandop at xs4all.nl (Michel van Dop) Date: Fri, 07 Dec 2018 13:14:12 +0100 Subject: [Icecast] https stream play 1 second and stop In-Reply-To: References: <954ee3dc9b2c530f262c877d8e236c92@xs4all.nl> <1544008217.1923.109.camel@de.loewenfelsen.net> <5d27e53b831c7cd1962f38b0b9b05b9b@xs4all.nl> <1544015347.1923.110.camel@de.loewenfelsen.net> <8ea43b850a889b15efdc322dde4fdcb5@xs4all.nl> Message-ID: <8092b25afa0da4482d39481128411cbf@xs4all.nl> Hi, Today we see big update voor CentOS 7 64bit include openssl 1:1.0.2k-16.el7 openssl-libs 1:1.0.2k-16.el7 Before update openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 Afther install the updates and reboot.. openssl version OpenSSL 1.0.2k-fips 26 Jan 2017... I do not understand.. i hope this update the version of opensssl and fixing the ssl problem in Icecast. Best regards, Michel Michel van Dop schreef op 2018-12-06 21:32: > Hi Gary, > > I change the type of encoder for the mountpoint what go wrong from mp3 to opus, but same problem. > No mp3 problem. > > I restart Icecast and it works again. I set the log on (4) debug mode hope i can find something. > > Best regards, > Michel > > Gary Dearth schreef op 2018-12-06 14:50: > > Thanks for your response Michel. I encode with Omnia AX/E Software so that it can be processed a bit and it has built in MP3 Encoders. I believe it is happening to all my streams, but I only use the mp3 codec. Was encouraged to hear that I wasn't the only one having an issue and look forward to some trouble shooting thoughts. I do not build my own packages so whatever OpenSSL version is in the win32 release on icecast.org is what I have used. > > Thanks > > Gary D > > FROM: Michel van Dop > SENT: Thursday, December 06, 2018 2:59 AM > TO: Icecast streaming server user discussions > CC: Gary Dearth > SUBJECT: Re: [Icecast] https stream play 1 second and stop > > Hi, > > What strikes me is that the problem is with a mp3 stream. We use in the same icecast stream FLAC and opus and the have not this problem. > Gary do you have this problem only on a mp3 stream? I use ProppFrexx onair Pro encoders for mp3. > And i see this problem on Sam Broadcaster Pro 2018.x (lame encoders). > > I must restart Icecast and it works fine for another week or two (same). I try to stop en start the encoder in ProppFrexx but i do not solve the problem. > > I send Philipp personally a stream url where it goes wrong now (not restarted). > > Best regards, > Michel > > Gary Dearth schreef op 2018-12-05 14:20: > > I have the same issue occur on a windows server 2008 running 2.4.3 and recently upgraded to 2.4.4 > I don't know what open ssl was packaged with it. It seems to run fine for a week or two and then all of a sudden it starts this same issue of playing one second and then stopping. Restart the service and it works fine for another week or two. But only an issue on https, the http streams are fine. Been dealing with this since beginning of year when we created the https streams for alexa use. Got my distro from the icecast.org repository. > > Gary D. > > -----Original Message----- > From: Icecast On Behalf Of Philipp Schafft > Sent: Wednesday, December 05, 2018 7:09 AM > To: Icecast streaming server user discussions > Subject: Re: [Icecast] https stream play 1 second and stop > > Good afternoon, > > On Wed, 2018-12-05 at 13:02 +0100, Michel van Dop wrote: > > Hi Philipp, > > We use OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS Linux release > 7.5.1804 > (Core) > > When we restart the Icecast stream the problem is gone. > > The problem is gone when you restart the STREAM or when you restart Icecast? > > Do you have an URL to such a stream for me? > > With best regards, > > Philipp Schafft schreef op 2018-12-05 12:10: > > Good morning, > > On Wed, 2018-12-05 at 11:29 +0100, Michel van Dop wrote: > > Hi, > > We have sometimes a problems with playing in https the stream > starts playing and stops in html5 or direct in the browser after a second. > If we use the same stream on http, there is no problem. I can not > find anything in the error log. > > We use Icecast 2.4.3. Is this problem solve in 2.4.4? > > There is no such bug known to us in Icecast. However: > There is a bug in some OpenSSL versions that cause this behaviour. > > Which OpenSSL version do you use? > > Please also note that 2.4.4 include a very important security fix > for URL Auth [0 [1]]. So upgrade to Icecast 2.4.4 is generally recommended. > > With best regards, > > [0] https://icecast.org/news/icecast-release_2_4_4/ [1] -- -- _______________________________________________ Icecast mailing list Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast -- Links: ------ [1] https://icecast.org/news/icecast-release_2_4_4/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvandop at xs4all.nl Sun Dec 9 20:44:03 2018 From: mvandop at xs4all.nl (Michel van Dop) Date: Sun, 09 Dec 2018 21:44:03 +0100 Subject: [Icecast] https stream play 1 second and stop In-Reply-To: References: <954ee3dc9b2c530f262c877d8e236c92@xs4all.nl> <1544008217.1923.109.camel@de.loewenfelsen.net> <5d27e53b831c7cd1962f38b0b9b05b9b@xs4all.nl> <1544015347.1923.110.camel@de.loewenfelsen.net> <8ea43b850a889b15efdc322dde4fdcb5@xs4all.nl> Message-ID: Hi, I bult saturday a new RPM for icecast 2.4.4 on the last version of CentOS Linux release 7.6.1810 (Core) include the openssl update. I run it on the debug mode (4). Tonight i have the same problem on https on mount /live a mp3 192k stream. It play 2 seconds and stop. (when i try to use include .m3u so /live.m3u he go to http in software player) Here is the debug error log. I hope you find them useful (see /live) : [2018-12-09 21:29:07] DBUG auth/add_authenticated_listener client authenticated, passed to source [2018-12-09 21:29:07] DBUG source/source_main Client added for mountpoint (/live) [2018-12-09 21:29:07] INFO source/source_main listener count on /live now 1 [2018-12-09 21:29:07] DBUG format/format_check_http_buffer processing pending client headers [2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (15) [2018-12-09 21:29:07] DBUG stats/modify_node_event update global connections (52301) [2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (16) [2018-12-09 21:29:07] DBUG stats/modify_node_event update global connections (52302) [2018-12-09 21:29:07] DBUG stats/modify_node_event update "/flac.flac" total_bytes_read (18373627904) [2018-12-09 21:29:07] DBUG stats/modify_node_event update "/flac.flac" total_bytes_sent (82768157916) [2018-12-09 21:29:07] DBUG stats/modify_node_event update global client_connections (50480) [2018-12-09 21:29:07] DBUG stats/modify_node_event update "/live" listeners (1) [2018-12-09 21:29:07] DBUG stats/modify_node_event update global listeners (12) [2018-12-09 21:29:07] DBUG stats/modify_node_event update global listener_connections (11687) [2018-12-09 21:29:07] DBUG client/client_send_bytes Client connection died [2018-12-09 21:29:07] DBUG source/source_main Client removed [2018-12-09 21:29:07] INFO source/source_main listener count on /live now 0 [2018-12-09 21:29:07] DBUG auth/add_listener_to_source max on /live is 400 (cur 0) [2018-12-09 21:29:07] DBUG auth/add_listener_to_source Added client to /live [2018-12-09 21:29:07] DBUG auth/add_authenticated_listener client authenticated, passed to source [2018-12-09 21:29:07] DBUG stats/modify_node_event update global listeners (11) [2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (15) [2018-12-09 21:29:07] DBUG stats/modify_node_event update "/live" listeners (0) [2018-12-09 21:29:07] DBUG stats/modify_node_event update global client_connections (50481) [2018-12-09 21:29:07] DBUG source/source_main Client added for mountpoint (/live) [2018-12-09 21:29:07] INFO source/source_main listener count on /live now 1 [2018-12-09 21:29:07] DBUG format/format_check_http_buffer processing pending client headers [2018-12-09 21:29:07] DBUG client/client_send_bytes Client connection died [2018-12-09 21:29:07] DBUG source/source_main Client removed [2018-12-09 21:29:07] INFO source/source_main listener count on /live now 0 Best regards, Michel Michel van Dop schreef op 2018-12-06 21:32: > Hi Gary, > > I change the type of encoder for the mountpoint what go wrong from mp3 to opus, but same problem. > No mp3 problem. > > I restart Icecast and it works again. I set the log on (4) debug mode hope i can find something. > > Best regards, > Michel > > Gary Dearth schreef op 2018-12-06 14:50: > > Thanks for your response Michel. I encode with Omnia AX/E Software so that it can be processed a bit and it has built in MP3 Encoders. I believe it is happening to all my streams, but I only use the mp3 codec. Was encouraged to hear that I wasn't the only one having an issue and look forward to some trouble shooting thoughts. I do not build my own packages so whatever OpenSSL version is in the win32 release on icecast.org is what I have used. > > Thanks > > Gary D > > FROM: Michel van Dop > SENT: Thursday, December 06, 2018 2:59 AM > TO: Icecast streaming server user discussions > CC: Gary Dearth > SUBJECT: Re: [Icecast] https stream play 1 second and stop > > Hi, > > What strikes me is that the problem is with a mp3 stream. We use in the same icecast stream FLAC and opus and the have not this problem. > Gary do you have this problem only on a mp3 stream? I use ProppFrexx onair Pro encoders for mp3. > And i see this problem on Sam Broadcaster Pro 2018.x (lame encoders). > > I must restart Icecast and it works fine for another week or two (same). I try to stop en start the encoder in ProppFrexx but i do not solve the problem. > > I send Philipp personally a stream url where it goes wrong now (not restarted). > > Best regards, > Michel > > Gary Dearth schreef op 2018-12-05 14:20: > > I have the same issue occur on a windows server 2008 running 2.4.3 and recently upgraded to 2.4.4 > I don't know what open ssl was packaged with it. It seems to run fine for a week or two and then all of a sudden it starts this same issue of playing one second and then stopping. Restart the service and it works fine for another week or two. But only an issue on https, the http streams are fine. Been dealing with this since beginning of year when we created the https streams for alexa use. Got my distro from the icecast.org repository. > > Gary D. > > -----Original Message----- > From: Icecast On Behalf Of Philipp Schafft > Sent: Wednesday, December 05, 2018 7:09 AM > To: Icecast streaming server user discussions > Subject: Re: [Icecast] https stream play 1 second and stop > > Good afternoon, > > On Wed, 2018-12-05 at 13:02 +0100, Michel van Dop wrote: > > Hi Philipp, > > We use OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS Linux release > 7.5.1804 > (Core) > > When we restart the Icecast stream the problem is gone. > > The problem is gone when you restart the STREAM or when you restart Icecast? > > Do you have an URL to such a stream for me? > > With best regards, > > Philipp Schafft schreef op 2018-12-05 12:10: > > Good morning, > > On Wed, 2018-12-05 at 11:29 +0100, Michel van Dop wrote: > > Hi, > > We have sometimes a problems with playing in https the stream > starts playing and stops in html5 or direct in the browser after a second. > If we use the same stream on http, there is no problem. I can not > find anything in the error log. > > We use Icecast 2.4.3. Is this problem solve in 2.4.4? > > There is no such bug known to us in Icecast. However: > There is a bug in some OpenSSL versions that cause this behaviour. > > Which OpenSSL version do you use? > > Please also note that 2.4.4 include a very important security fix > for URL Auth [0 [1]]. So upgrade to Icecast 2.4.4 is generally recommended. > > With best regards, > > [0] https://icecast.org/news/icecast-release_2_4_4/ [1] -- -- _______________________________________________ Icecast mailing list Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast -- Links: ------ [1] https://icecast.org/news/icecast-release_2_4_4/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From racuk12 at gmail.com Fri Dec 14 15:42:37 2018 From: racuk12 at gmail.com (Robert Chalmers) Date: Fri, 14 Dec 2018 15:42:37 +0000 Subject: [Icecast] What is the web/listen file? Message-ID: <77A44B44-FDF1-4856-A351-F4A652F6B2E6@gmail.com> Hi What is expected by the ?checking for file /listen (/usr/local/share/Icecast/web/listen) ..... no such file or directory In logs ? Thanks Robert From geoff at QuiteLikely.com Fri Dec 14 21:05:38 2018 From: geoff at QuiteLikely.com (Geoff Shang) Date: Fri, 14 Dec 2018 21:05:38 +0000 (GMT) Subject: [Icecast] What is the web/listen file? In-Reply-To: <77A44B44-FDF1-4856-A351-F4A652F6B2E6@gmail.com> References: <77A44B44-FDF1-4856-A351-F4A652F6B2E6@gmail.com> Message-ID: On Fri, 14 Dec 2018, Robert Chalmers wrote: > What is expected by the ?checking for file /listen (/usr/local/share/Icecast/web/listen) > ..... no such file or directory > In logs Someone is calling your server at :/listen Presumably the /listen mount doesn't exist. If fileserve is enabled, which it is by default, Icecast then looks to see if a file called listen is available in the configured directory. the /listen endpoint has some significance for a different server product if my memory serves me correctly, but I don't recall exactly which one as it's been awhile since I did a lot with this stuff. \HTH, Geoff. From mvandop at xs4all.nl Sat Dec 15 09:06:08 2018 From: mvandop at xs4all.nl (Michel van Dop) Date: Sat, 15 Dec 2018 10:06:08 +0100 Subject: [Icecast] What is the web/listen file? In-Reply-To: References: <77A44B44-FDF1-4856-A351-F4A652F6B2E6@gmail.com> Message-ID: Hi, You can use a alias for listen to forward to a active mountpoint. I use this alias for old shoutcast listeners. /live is my active mountpoint in the example. Best regards, Michel Geoff Shang schreef op 2018-12-14 22:05: > On Fri, 14 Dec 2018, Robert Chalmers wrote: > >> What is expected by the "checking for file /listen (/usr/local/share/Icecast/web/listen) >> ..... no such file or directory >> In logs > > Someone is calling your server at :/listen > > Presumably the /listen mount doesn't exist. If fileserve is enabled, which it is by default, Icecast then looks to see if a file called listen is available in the configured directory. > > the /listen endpoint has some significance for a different server product if my memory serves me correctly, but I don't recall exactly which one as it's been awhile since I did a lot with this stuff. > > \HTH, > Geoff. > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From gernotm189 at gmail.com Mon Dec 17 09:56:49 2018 From: gernotm189 at gmail.com (Gernot Meyer) Date: Mon, 17 Dec 2018 12:56:49 +0300 Subject: [Icecast] Geoblocking on Icecast stations (radionomy) Message-ID: Hi, I stumpled upon Icecast, but I effectively can only play few stations because somehow most of the stations that I'm interested in use the radionomy service. After some research I found out that I'm not the only one and that this company is blocking many countries worldwide: https://www.google.com/search?q=this+radio+station+is+not+available+in+your+country+site:board.radionomy.com Any chance to add a filter that filters out all stations relying on radionomy? I'm not planning on using my university's VPN for streaming music and it's quite a hassle finding a station that actually works. As the premise of the Xiph.Org Foundation is to "support and develop free, open protocols and software to serve the public, developer and business markets", it seems like a rather odd choice that one would include radio stations that rely on a service that blocks out a good deal of the worldwide population. Best regards, Gernot Meyer From lion at lion.leolix.org Mon Dec 17 14:17:21 2018 From: lion at lion.leolix.org (Philipp Schafft) Date: Mon, 17 Dec 2018 14:17:21 +0000 Subject: [Icecast] Geoblocking on Icecast stations (radionomy) In-Reply-To: References: Message-ID: <1545056241.4412.32.camel@lion.leolix.org> Good afternoon, On Mon, 2018-12-17 at 12:56 +0300, Gernot Meyer wrote: > Hi, > > I stumpled upon Icecast, but I effectively can only play few stations > because somehow most of the stations that I'm interested in use the > radionomy service. After some research I found out that I'm not the > only one and that this company is blocking many countries worldwide: > https://www.google.com/search?q=this+radio+station+is+not+available+in+your+country+site:board.radionomy.com > > Any chance to add a filter that filters out all stations relying on > radionomy? If they have a common feature that would be possible. But this is more a question for our YP admins. > I'm not planning on using my university's VPN for streaming > music and it's quite a hassle finding a station that actually works. > > As the premise of the Xiph.Org Foundation is to "support and develop > free, open protocols and software to serve the public, developer and > business markets", it seems like a rather odd choice that one would > include radio stations that rely on a service that blocks out a good > deal of the worldwide population. It's very simple: The directory is free for everyone to list. There is no check if the station is inline with our mission. It's just that their servers submit their streams on our servers just as everyone else does. There is no action on our side to include them. An action would be to remove them. And that is something that needs to be discussed. Blocking some submissions based on non-technical factors is always a political thing and musst be discussed on that level. With best regards, -- Philipp. (Rah of PH2) -------------- 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 webmaster at berean-biblechurch.org Fri Dec 28 14:55:55 2018 From: webmaster at berean-biblechurch.org (webmaster at berean-biblechurch.org) Date: Fri, 28 Dec 2018 08:55:55 -0600 Subject: [Icecast] separation of web interface and mountpoint Message-ID: <2b8805bd7a28fc7d1b7af6e37183b308@berean-biblechurch.org> It looks like default behavior is for Icecast to expose its web interface on the same address and port as any mountpoint. E.g.: mountpoint = https://server.com/listentome web app = https://server.com/ I'd like to restrict the web interface to ONLY A CERTAIN IP ADDRESS AND TCP PORT so that it is not accessible on the public IP. E.g.: mountpoint = https://server.com/listentome web app = https://192.168.1.10:8000/ Is this possible? In other words, I don't want any web interface to be available to the internet. I want the web UI to be available only to my local machine/LAN and the mountpoint (stream) available to the internet. Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: From phschafft at de.loewenfelsen.net Fri Dec 28 16:40:36 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Fri, 28 Dec 2018 16:40:36 +0000 Subject: [Icecast] separation of web interface and mountpoint In-Reply-To: <2b8805bd7a28fc7d1b7af6e37183b308@berean-biblechurch.org> References: <2b8805bd7a28fc7d1b7af6e37183b308@berean-biblechurch.org> Message-ID: <1546015236.5167.12.camel@de.loewenfelsen.net> Good afternoon, On Fri, 2018-12-28 at 08:55 -0600, webmaster at berean-biblechurch.org wrote: > It looks like default behavior is for Icecast to expose its web > interface on the same address and port as any mountpoint. E.g.: > > mountpoint = https://server.com/listentome > web app = https://server.com/ Yes. Icecast supports all operations on all sockets. > I'd like to restrict the web interface to ONLY A CERTAIN IP ADDRESS AND > TCP PORT so that it is not accessible on the public IP. E.g.: > > mountpoint = https://server.com/listentome > web app = https://192.168.1.10:8000/ It's a bad idea to use IP addresses. If at all, you should add a DNS record for it in your internal DNS zone. > Is this possible? This depends on your version. With Icecast 2.4.x (stable) it is mostly possible. With Icecast 2.5.x (development) it is possible but requires some configuration. > In other words, I don't want any web interface to be available to the > internet. I want the web UI to be available only to my local > machine/LAN and the mountpoint (stream) available to the internet. The big point here is: Why are you trying to do this?: * Mounts can be set as hidden so they are not listed. If listing mounts is the problem. * If you don't like the public WI at all, just point your to an empty directory. You can also modify the XSLT files to match your needs. * The admin interface can be secured using a secure password. This will make keep it available and secure. * Hiding the version number: Doing this makes it harder for debugging. However it does not improve security at all (as many think) as you can fingerprint the version number anyway. * The authentication system can be used for precise access control. (This is even more true for Icecast 2.5.x). 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: