From db76 at riseup.net Tue May 1 11:00:52 2018 From: db76 at riseup.net (Damian) Date: Tue, 1 May 2018 21:00:52 +1000 Subject: [Icecast] EROR connection/_handle_connection Wrong request type from client Message-ID: Hi, I have been digging through the icecast mailing list archives trying to find out the meaning of this recurring message in my error.log [2018-05-01 19:50:16] EROR connection/_handle_connection Wrong request type from client [2018-05-01 19:50:16] EROR connection/_handle_connection Wrong request type from client [2018-05-01 19:50:16] INFO source/source_main listener count on /Systrum now 1 [2018-05-01 19:50:16] INFO source/source_main listener count on /Systrum now 0 Is anyone able to tell me either what this means or perhaps refer me to where I can find this answer? Any help will be appreciated. Damian - - - I prefer to use encrypted email. My public key fingerprint is 77CC 9087 0A92 F55D 75A3 660B 68F2 1FA9 B26E CAC7 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From teddy.xiph at rilliot.fr Tue May 1 15:16:33 2018 From: teddy.xiph at rilliot.fr (Teddy Rilliot) Date: Tue, 01 May 2018 17:16:33 +0200 Subject: [Icecast] EROR connection/_handle_connection Wrong request type from client In-Reply-To: References: Message-ID: Hi, AFAIK, icecast only supports specific HTTP request methods (GET for listeners, PUT/SOURCE for sources). This message is logged when a client uses an unsupported request method (such as HEAD or POST). Please note that this might be inaccurate, but I saw this kind of logs during a development that involved unsupported request methods. ? Teddy Le 2018-05-01 13:00, Damian a ?crit?: > Hi, > > I have been digging through the icecast mailing list archives trying > to find out the meaning of this recurring message in my error.log > > [2018-05-01 19:50:16] EROR connection/_handle_connection Wrong > request type from client > [2018-05-01 19:50:16] EROR connection/_handle_connection Wrong > request type from client > [2018-05-01 19:50:16] INFO source/source_main listener count on > /Systrum now 1 > [2018-05-01 19:50:16] INFO source/source_main listener count on > /Systrum now 0 > > Is anyone able to tell me either what this means or perhaps refer me > to where I can find this answer? > Any help will be appreciated. > Damian > > - - -I prefer to use encrypted email. > My public key fingerprint is 77CC 9087 0A92 F55D 75A3 660B 68F2 1FA9 > B26E CAC7 > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From db76 at riseup.net Wed May 2 12:07:35 2018 From: db76 at riseup.net (Damian) Date: Wed, 2 May 2018 22:07:35 +1000 Subject: [Icecast] Icecast Digest, Vol 167, Issue 2 In-Reply-To: References: Message-ID: <8E25AE8E-846C-4EBA-B7BA-7E18BBBEFC25@riseup.net> Thanks for the reply. So then does this message indicate an issue with my setup (I use Liquidsoap to stream to Icecast) or an issue with a listener client? It looks like the listener count drops immediately after someone connects which to seems like a problem at the listeners end. > On 2 May 2018, at 22:00, icecast-request at xiph.org wrote: > > Send Icecast mailing list submissions to > icecast at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/icecast > or, via email, send a message with subject or body 'help' to > icecast-request at xiph.org > > You can reach the person managing the list at > icecast-owner at xiph.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Icecast digest..." > > > Today's Topics: > > 1. Re: EROR connection/_handle_connection Wrong request type > from client (Teddy Rilliot) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 01 May 2018 17:16:33 +0200 > From: Teddy Rilliot > To: Icecast streaming server user discussions > Subject: Re: [Icecast] EROR connection/_handle_connection Wrong > request type from client > Message-ID: > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi, > > AFAIK, icecast only supports specific HTTP request methods (GET for > listeners, PUT/SOURCE for sources). > This message is logged when a client uses an unsupported request method > (such as HEAD or POST). > > Please note that this might be inaccurate, but I saw this kind of logs > during a development that involved unsupported request methods. > > ? Teddy > > > Le 2018-05-01 13:00, Damian a ?crit : >> Hi, >> >> I have been digging through the icecast mailing list archives trying >> to find out the meaning of this recurring message in my error.log >> >> [2018-05-01 19:50:16] EROR connection/_handle_connection Wrong >> request type from client >> [2018-05-01 19:50:16] EROR connection/_handle_connection Wrong >> request type from client >> [2018-05-01 19:50:16] INFO source/source_main listener count on >> /Systrum now 1 >> [2018-05-01 19:50:16] INFO source/source_main listener count on >> /Systrum now 0 >> >> Is anyone able to tell me either what this means or perhaps refer me >> to where I can find this answer? >> Any help will be appreciated. >> Damian >> >> - - -I prefer to use encrypted email. >> My public key fingerprint is 77CC 9087 0A92 F55D 75A3 660B 68F2 1FA9 >> B26E CAC7 >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > > > ------------------------------ > > End of Icecast Digest, Vol 167, Issue 2 > *************************************** From phschafft at de.loewenfelsen.net Wed May 2 12:18:55 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Wed, 02 May 2018 12:18:55 +0000 Subject: [Icecast] EROR connection/_handle_connection Wrong request type from client In-Reply-To: References: Message-ID: <1525263535.12446.62.camel@de.loewenfelsen.net> Good afternoon, On Tue, 2018-05-01 at 17:16 +0200, Teddy Rilliot wrote: > Hi, > > AFAIK, icecast only supports specific HTTP request methods (GET for > listeners, PUT/SOURCE for sources). > This message is logged when a client uses an unsupported request method > (such as HEAD or POST). This is correct. Some listen clients try a HEAD request first (most of no good reason). You can also see the requests in your access log. Look for lines like this: 127.0.0.1 - - [02/May/2018:12:17:08 +0000] "HEAD / HTTP/1.1" 400 430 "-" "Wget/1.18 (linux-gnu)" 0 ^^^^ With best regards, > Le 2018-05-01 13:00, Damian a ?crit : > > Hi, > > > > I have been digging through the icecast mailing list archives trying > > to find out the meaning of this recurring message in my error.log > > > > [2018-05-01 19:50:16] EROR connection/_handle_connection Wrong > > request type from client > > [2018-05-01 19:50:16] EROR connection/_handle_connection Wrong > > request type from client > > [2018-05-01 19:50:16] INFO source/source_main listener count on > > /Systrum now 1 > > [2018-05-01 19:50:16] INFO source/source_main listener count on > > /Systrum now 0 > > > > Is anyone able to tell me either what this means or perhaps refer me > > to where I can find this answer? > > Any help will be appreciated. -- 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 db76 at riseup.net Fri May 4 01:11:22 2018 From: db76 at riseup.net (Damian) Date: Thu, 03 May 2018 18:11:22 -0700 Subject: [Icecast] EROR connection/_handle_connection Wrong request type > from client In-Reply-To: References: Message-ID: Thanks for clarifying that Philipp. Yeah, I compared the time stamps in the error.log and access.log (below) and saw the corresponding HEAD requests. I've been getting a lot of these so I thought that there was something I could do to allow these clients to connect to the stream. I guess I just need to ignore them. Thanks Damian Snippet from error.log [2018-05-04 00:28:17] EROR connection/_handle_connection Wrong request type from client [2018-05-04 00:28:17] EROR connection/_handle_connection Wrong request type from client Snippet for access log 158.69.38.195 - - [04/May/2018:00:28:17 +1000] "HEAD /Systrum HTTP/1.1" 400 336 "-" "curl/7.29.0" 0 158.69.38.195 - - [04/May/2018:00:28:17 +1000] "HEAD /Systrum HTTP/1.1" 400 336 "-" "curl/7.29.0" 0 > > This is correct. Some listen clients try a HEAD request first (most of > no good reason). You can also see the requests in your access log. > > Look for lines like this: > > 127.0.0.1 - - [02/May/2018:12:17:08 +0000] "HEAD / HTTP/1.1" 400 430 > "-" "Wget/1.18 (linux-gnu)" 0 > From phschafft at de.loewenfelsen.net Fri May 4 06:15:27 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Fri, 04 May 2018 06:15:27 +0000 Subject: [Icecast] EROR connection/_handle_connection Wrong request type > from client In-Reply-To: References: Message-ID: <1525414527.12446.84.camel@de.loewenfelsen.net> Good morning, On Thu, 2018-05-03 at 18:11 -0700, Damian wrote: > Thanks for clarifying that Philipp. > > Yeah, I compared the time stamps in the error.log and access.log (below) > and saw the corresponding HEAD requests. I've been getting a lot of > these so I thought that there was something I could do to allow these > clients to connect to the stream. The HEAD requests are basically: Hello, what are you? They would not result in a connect to the stream anyway, the answer would just be 'Audio/Video data!'. I also think that for playing media streams they add more trouble than they are worth (Hint to developers: They only add race conditions.) > I guess I just need to ignore them. Yes. That's the only option you have as a server operator. I'm glad my answerer helped you. With best regards, > Snippet from error.log > [2018-05-04 00:28:17] EROR connection/_handle_connection Wrong request > type from client > [2018-05-04 00:28:17] EROR connection/_handle_connection Wrong request > type from client > > Snippet for access log > 158.69.38.195 - - [04/May/2018:00:28:17 +1000] "HEAD /Systrum HTTP/1.1" > 400 336 "-" "curl/7.29.0" 0 > 158.69.38.195 - - [04/May/2018:00:28:17 +1000] "HEAD /Systrum HTTP/1.1" > 400 336 "-" "curl/7.29.0" 0 > > > > > > This is correct. Some listen clients try a HEAD request first (most of > > no good reason). You can also see the requests in your access log. > > > > Look for lines like this: > > > > 127.0.0.1 - - [02/May/2018:12:17:08 +0000] "HEAD / HTTP/1.1" 400 430 > > "-" "Wget/1.18 (linux-gnu)" 0 -- 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 subscription at nextdial.com.br Sun May 6 11:35:15 2018 From: subscription at nextdial.com.br (subscription at nextdial.com.br) Date: Sun, 6 May 2018 08:35:15 -0300 Subject: [Icecast] How to log querystring values? Message-ID: Hello, I need to get some values passed in the querystring request in the log file. Something like that bellow: ie: "GET /radio?id=1 HTTP/1.1" instead of only "GET /radio HTTP/1.1" Do I need to change something in the source and compile? Or there is another way? Best, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From lion at lion.leolix.org Sun May 6 12:23:53 2018 From: lion at lion.leolix.org (Philipp Schafft) Date: Sun, 06 May 2018 12:23:53 +0000 Subject: [Icecast] How to log querystring values? In-Reply-To: References: Message-ID: <1525609433.1843.18.camel@lion.leolix.org> Dear Mr./Ms. subscription, On Sun, 2018-05-06 at 08:35 -0300, subscription at nextdial.com.br wrote: > I need to get some values passed in the querystring request in the log > file. > > Something like that bellow: > > ie: "GET /radio?id=1 HTTP/1.1" instead of only "GET /radio HTTP/1.1" > > Do I need to change something in the source and compile? Or there is > another way? What exactly is your goal? Maybe you can give us a bit of an understanding of the context. Query parameters are to be interpreted by the server, in this case Icecast, not external software. Therefore I suspect that there is a better solution for your problem. With best regards, -- Philipp. (Rah of PH2) From subscription at nextdial.com.br Sun May 6 13:23:48 2018 From: subscription at nextdial.com.br (subscription at nextdial.com.br) Date: Sun, 6 May 2018 10:23:48 -0300 Subject: [Icecast] How to log querystring values? In-Reply-To: <1525609433.1843.18.camel@lion.leolix.org> References: <1525609433.1843.18.camel@lion.leolix.org> Message-ID: Dear Philipp, Thanks for you reply. My goal is to show in our analytics page segmented data (official apps, partner apps, third-party apps, demographic and geo). To do so each app pass some values in the query string (ie: app id, user id, lat, lng). And I need to know those values in order to do that. Today we are using nginx as a reverse proxy to Icecast to get those data but it double the cpu/mem usage =( I am welcome to any idea. =) Best, Thiago ---------------------------------------- De: "Philipp Schafft" Enviado: domingo, 6 de maio de 2018 09:30 Para: subscription at nextdial.com.br, "Icecast streaming server user discussions" Assunto: Re: [Icecast] How to log querystring values? Dear Mr./Ms. subscription, On Sun, 2018-05-06 at 08:35 -0300, subscription at nextdial.com.br wrote: > I need to get some values passed in the querystring request in the log > file. > > Something like that bellow: > > ie: "GET /radio?id=1 HTTP/1.1" instead of only "GET /radio HTTP/1.1" > > Do I need to change something in the source and compile? Or there is > another way? What exactly is your goal? Maybe you can give us a bit of an understanding of the context. Query parameters are to be interpreted by the server, in this case Icecast, not external software. Therefore I suspect that there is a better solution for your problem. With best regards, -- Philipp. (Rah of PH2) -------------- next part -------------- An HTML attachment was scrubbed... URL: From phschafft at de.loewenfelsen.net Mon May 7 06:28:59 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Mon, 07 May 2018 06:28:59 +0000 Subject: [Icecast] How to log querystring values? In-Reply-To: References: <1525609433.1843.18.camel@lion.leolix.org> Message-ID: <1525674539.1843.36.camel@de.loewenfelsen.net> Good Morning Thiago, On Sun, 2018-05-06 at 10:23 -0300, subscription at nextdial.com.br wrote: > Dear Philipp, > > Thanks for you reply. > > My goal is to show in our analytics page segmented data (official apps, > partner apps, third-party apps, demographic and geo). > To do so each app pass some values in the query string (ie: app id, > user id, lat, lng). And I need to know those values in order to do > that. I would recommend to add those to (a) custom header field(s). You can then log that by using URL auth. This is to the standards and will also add more flexibility to the system, such as real time stats. If you really, really need to pass the parameters using query string parameters we could implement a separate logfile for that. That would keep the main log intact and provide a (probably better) parseable log for those data. (If you're interested in this option contact me off-list.) > Today we are using nginx as a reverse proxy to Icecast to get those data > but it double the cpu/mem usage =( using a rproxy is not ideal and should be avoided. :) with best regards, > ---------------------------------------- > De: "Philipp Schafft" > Enviado: domingo, 6 de maio de 2018 09:30 > Para: subscription at nextdial.com.br, "Icecast streaming server user > discussions" > Assunto: Re: [Icecast] How to log querystring values? > Dear Mr./Ms. subscription, > > On Sun, 2018-05-06 at 08:35 -0300, subscription at nextdial.com.br wrote: > > I need to get some values passed in the querystring request in the log > > file. > > > > Something like that bellow: > > > > ie: "GET /radio?id=1 HTTP/1.1" instead of only "GET /radio HTTP/1.1" > > > > Do I need to change something in the source and compile? Or there is > > another way? > > What exactly is your goal? Maybe you can give us a bit of an > understanding of the context. > > Query parameters are to be interpreted by the server, in this case > Icecast, not external software. Therefore I suspect that there is a > better solution for your problem. -- 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 subscription at nextdial.com.br Mon May 7 12:09:44 2018 From: subscription at nextdial.com.br (subscription at nextdial.com.br) Date: Mon, 7 May 2018 09:09:44 -0300 Subject: [Icecast] How to log querystring values? In-Reply-To: <1525674539.1843.36.camel@de.loewenfelsen.net> References: <1525609433.1843.18.camel@lion.leolix.org> <1525674539.1843.36.camel@de.loewenfelsen.net> Message-ID: Philipp, Thanks so much for your time and relpy. This dawn, before read your email, I worked to implement the URL authentication and it worked like a charm. I am still using querystring instead of custom header field because I have no control over the player. But, the excelent news is, no more rproxy! =) And you were right, this way I have more possibilities than before! Again, thanks so much and congrats for the awesome job. ps: Icecast is so far more efficient than SHOUTcast and a lot websites says they have no big differences, why? Best, Thiago ---------------------------------------- De: "Philipp Schafft" Enviado: segunda-feira, 7 de maio de 2018 03:40 Para: subscription at nextdial.com.br, "Icecast streaming server user discussions" Assunto: Re: [Icecast] How to log querystring values? Good Morning Thiago, On Sun, 2018-05-06 at 10:23 -0300, subscription at nextdial.com.br wrote: > Dear Philipp, > > Thanks for you reply. > > My goal is to show in our analytics page segmented data (official apps, > partner apps, third-party apps, demographic and geo). > To do so each app pass some values in the query string (ie: app id, > user id, lat, lng). And I need to know those values in order to do > that. I would recommend to add those to (a) custom header field(s). You can then log that by using URL auth. This is to the standards and will also add more flexibility to the system, such as real time stats. If you really, really need to pass the parameters using query string parameters we could implement a separate logfile for that. That would keep the main log intact and provide a (probably better) parseable log for those data. (If you're interested in this option contact me off-list.) > Today we are using nginx as a reverse proxy to Icecast to get those data > but it double the cpu/mem usage =( using a rproxy is not ideal and should be avoided. :) with best regards, > ---------------------------------------- > De: "Philipp Schafft" > Enviado: domingo, 6 de maio de 2018 09:30 > Para: subscription at nextdial.com.br, "Icecast streaming server user > discussions" > Assunto: Re: [Icecast] How to log querystring values? > Dear Mr./Ms. subscription, > > On Sun, 2018-05-06 at 08:35 -0300, subscription at nextdial.com.br wrote: > > I need to get some values passed in the querystring request in the log > > file. > > > > Something like that bellow: > > > > ie: "GET /radio?id=1 HTTP/1.1" instead of only "GET /radio HTTP/1.1" > > > > Do I need to change something in the source and compile? Or there is > > another way? > > What exactly is your goal? Maybe you can give us a bit of an > understanding of the context. > > Query parameters are to be interpreted by the server, in this case > Icecast, not external software. Therefore I suspect that there is a > better solution for your problem. -- 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 oskar.vilkevuori at ovt.fi Mon May 7 19:07:22 2018 From: oskar.vilkevuori at ovt.fi (Oskar Vilkevuori) Date: Mon, 7 May 2018 22:07:22 +0300 Subject: [Icecast] mp3 stream and Chrome v.65.0.33.25.181 In-Reply-To: <1B5D70C2-EF9D-4B84-B917-52D2F35BE580@ovt.fi> References: <50D2BA25-172E-4F8C-A320-69D8246D29BF@ovt.fi> <8CABBA43-95F9-43C4-9BC3-EF94470B858E@gmail.com> <1B5D70C2-EF9D-4B84-B917-52D2F35BE580@ovt.fi> Message-ID: Hi there, How to validate that all the parameters are the same with intro and the stream? Moimoi, Oskar Vilkevuori > On 28 Apr 2018, at 23.38, Oskar Vilkevuori wrote: > > Hi there, > > mux=raw made the change. > > Thanks! > > Moimoi, > > Oskar Vilkevuori > >> On 28 Apr 2018, at 23.07, Marvin Scholz > wrote: >> >> >> >> On 28 Apr 2018, at 21:46, Oskar Vilkevuori wrote: >> >>> Hi there, >>> >>> I have used VLC 0.9.9 on Windows platform for streaming audio to icecast2 for years. Had no problems. Since Google Chrome v.65.0.33.25.181 I ran into problems. Stream will play couple of minutes and then stop. >>> >>> Is there something fundamentally wrong with my configuration in vlm configuration: >>> >>> output #transcode{acodec=mp3,ab=128,channels=2}:duplicate{dst=std{access=shout{mp3=1,bitrate=128},mux=mpeg1,dst=source:hacme at 185.139.168.34 :8000/vara},dst=std{access=shout{mp3=1,bitrate=128},mux=mpeg1,dst=source:hacme at 185.139.168.36 :8000/vara}} >>> >>> http://185.139.168.34:8000/vara >>> >>> http://185.139.168.36:8000/vara >>> >>> Yours,, >>> >>> Oskar Vilkevuori >> Hi, >> >> Wow, VLC 0.9.9 is nearly a decade old, you really should update to a newer >> version. >> >> In your MRL, instead of mux=mpeg1 you should use mux=raw, afaik. Do you have a intro >> configured in Icecast? If yes, you need to ensure that all parameters of the file match >> your stream. >> >>> _______________________________________________ >>> Icecast mailing list >>> Icecast at xiph.org >>> http://lists.xiph.org/mailman/listinfo/icecast >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phschafft at de.loewenfelsen.net Tue May 8 05:51:50 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Tue, 08 May 2018 05:51:50 +0000 Subject: [Icecast] How to log querystring values? In-Reply-To: References: <1525609433.1843.18.camel@lion.leolix.org> <1525674539.1843.36.camel@de.loewenfelsen.net> Message-ID: <1525758710.1843.52.camel@de.loewenfelsen.net> Good morning, On Mon, 2018-05-07 at 09:09 -0300, subscription at nextdial.com.br wrote: > Philipp, > > Thanks so much for your time and relpy. Haven't done much yet. :) > This dawn, before read your email, I worked to implement the URL > authentication and it worked like a charm. I am still using > querystring instead of custom header field because I have no control > over the player. But, the excelent news is, no more rproxy! =) Perfect. :) > And you were right, this way I have more possibilities than before! It is. I really think that url auth is one of the best features we have. :) It solves a lot of complicated problems nicely. > Again, thanks so much and congrats for the awesome job. > > ps: Icecast is so far more efficient than SHOUTcast and a lot > websites says they have no big differences, why? I think it's because they run low-traffic streams. If your streaming solution uses < 1% of the machine's resources, nobody cares. That is different for those who push streams to thousands of listeners. With best regards, > ---------------------------------------- > De: "Philipp Schafft" > Enviado: segunda-feira, 7 de maio de 2018 03:40 > Para: subscription at nextdial.com.br, "Icecast streaming server user discussions" > Assunto: Re: [Icecast] How to log querystring values? > Good Morning Thiago, > > On Sun, 2018-05-06 at 10:23 -0300, subscription at nextdial.com.br wrote: > > Dear Philipp, > > > > Thanks for you reply. > > > > My goal is to show in our analytics page segmented data (official apps, > > partner apps, third-party apps, demographic and geo). > > > To do so each app pass some values in the query string (ie: app id, > > user id, lat, lng). And I need to know those values in order to do > > that. > > I would recommend to add those to (a) custom header field(s). You can > then log that by using URL auth. This is to the standards and will also > add more flexibility to the system, such as real time stats. > > If you really, really need to pass the parameters using query string > parameters we could implement a separate logfile for that. That would > keep the main log intact and provide a (probably better) parseable log > for those data. (If you're interested in this option contact me > off-list.) > > > Today we are using nginx as a reverse proxy to Icecast to get those data > > but it double the cpu/mem usage =( > > using a rproxy is not ideal and should be avoided. :) > > with best regards, > > > ---------------------------------------- > > De: "Philipp Schafft" > > Enviado: domingo, 6 de maio de 2018 09:30 > > Para: subscription at nextdial.com.br, "Icecast streaming server user > > discussions" > > Assunto: Re: [Icecast] How to log querystring values? > > Dear Mr./Ms. subscription, > > > > On Sun, 2018-05-06 at 08:35 -0300, subscription at nextdial.com.br wrote: > > > I need to get some values passed in the querystring request in the log > > > file. > > > > > > Something like that bellow: > > > > > > ie: "GET /radio?id=1 HTTP/1.1" instead of only "GET /radio HTTP/1.1" > > > > > > Do I need to change something in the source and compile? Or there is > > > another way? > > > > What exactly is your goal? Maybe you can give us a bit of an > > understanding of the context. > > > > Query parameters are to be interpreted by the server, in this case > > Icecast, not external software. Therefore I suspect that there is a > > better solution for your problem. > -- 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 db76 at riseup.net Sun May 13 01:59:18 2018 From: db76 at riseup.net (Damian) Date: Sun, 13 May 2018 11:59:18 +1000 Subject: [Icecast] Parsing status-son.xsl Message-ID: <9975D294-5FAC-4199-A1C9-EA01FE0EC55C@riseup.net> Hi, I realise that the web is littered with posts and discussions concerning the topic of getting icecast stats from the xsl files (status-son.xsl) in the icecast web directory. As you may know, many of the solutions are outdated and example links are broken. I have limited knowledge of how to write my own javascript to get this info to display on my own website. Wondering if anyone can refer me to a currently working example or site that explains how to write my own JS to do this? Alternatively, I am happy to pay someone for their time or script. Damian - - - I prefer to use encrypted email. My public key fingerprint is 77CC 9087 0A92 F55D 75A3 660B 68F2 1FA9 B26E CAC7 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From db76 at riseup.net Sun May 13 05:10:59 2018 From: db76 at riseup.net (Damian) Date: Sun, 13 May 2018 15:10:59 +1000 Subject: [Icecast] Fwd: Parsing status-json.xsl References: <9975D294-5FAC-4199-A1C9-EA01FE0EC55C@riseup.net> Message-ID: Apologies, the previous email should have read status-json.xsl Begin forwarded message: > From: Damian > Date: 13 May 2018 at 11:59:18 AEST > To: icecast at xiph.org > Subject: Parsing status-son.xsl > > Hi, > > I realise that the web is littered with posts and discussions concerning the topic of getting icecast stats from the xsl files (status-son.xsl) in the icecast web directory. As you may know, many of the solutions are outdated and example links are broken. I have limited knowledge of how to write my own javascript to get this info to display on my own website. Wondering if anyone can refer me to a currently working example or site that explains how to write my own JS to do this? Alternatively, I am happy to pay someone for their time or script. > > Damian > > - - - > I prefer to use encrypted email. > My public key fingerprint is 77CC 9087 0A92 F55D 75A3 660B 68F2 1FA9 B26E CAC7 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From subscription at nextdial.com.br Mon May 14 12:35:39 2018 From: subscription at nextdial.com.br (subscription at nextdial.com.br) Date: Mon, 14 May 2018 09:35:39 -0300 Subject: [Icecast] Why current mount connection don't close after remove from config and reload? In-Reply-To: References: Message-ID: <28136f7b93ce45d9903e68a8416ff3c8@nextdial.com.br> Hello, After removing a mount from the xml config file and reloading the Icecast with the bellow command why it don't close the current mount connection? /etc/init.d/icecast2 reload There is another way? Best, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From jake at jakebriggs.com Mon May 14 19:22:48 2018 From: jake at jakebriggs.com (Jake) Date: Tue, 15 May 2018 07:22:48 +1200 Subject: [Icecast] Why current mount connection don't close after remove from config and reload? In-Reply-To: <28136f7b93ce45d9903e68a8416ff3c8@nextdial.com.br> References: <28136f7b93ce45d9903e68a8416ff3c8@nextdial.com.br> Message-ID: Well I am only guessing here, but I suspect if icecast works like other daemons reload just reloads the config but doesn't terminate current connections. You probably want /etc/init.d/icecast restart On 15 May 2018 12:35:39 AM NZST, "subscription at nextdial.com.br" wrote: >Hello, > >After removing a mount from the xml config file and reloading the >Icecast >with the bellow command why it don't close the current mount >connection? > > /etc/init.d/icecast2 reload > > There is another way? > > Best, > Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From subscription at nextdial.com.br Mon May 14 19:54:39 2018 From: subscription at nextdial.com.br (subscription at nextdial.com.br) Date: Mon, 14 May 2018 16:54:39 -0300 Subject: [Icecast] Why current mount connection don't close after remove from config and reload? In-Reply-To: References: <28136f7b93ce45d9903e68a8416ff3c8@nextdial.com.br> Message-ID: <26d0ba3b25e246bcb6ce585fb9f12895@nextdial.com.br> Hello Jake, Thanks for you reply. If I restart all listeners's connections would be droped (not only those related to the droped mount). Nginx, for example, would reload the configuration droping the server/location that don't exists anymore and active the new ones. Icecast has not the same behaviour. Am I wrong? Is there any other way to do what I want to do? Best, Thiago ---------------------------------------- De: "Jake" Enviado: segunda-feira, 14 de maio de 2018 16:28 Para: subscription at nextdial.com.br, "Icecast streaming server user discussions" Assunto: Re: [Icecast] Why current mount connection don't close after remove from config and reload? Well I am only guessing here, but I suspect if icecast works like other daemons reload just reloads the config but doesn't terminate current connections. You probably want /etc/init.d/icecast restart On 15 May 2018 12:35:39 AM NZST, "subscription at nextdial.com.br" wrote: Hello, After removing a mount from the xml config file and reloading the Icecast with the bellow command why it don't close the current mount connection? /etc/init.d/icecast2 reload There is another way? Best, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From phschafft at de.loewenfelsen.net Tue May 15 08:42:29 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Tue, 15 May 2018 08:42:29 +0000 Subject: [Icecast] Why current mount connection don't close after remove from config and reload? In-Reply-To: <26d0ba3b25e246bcb6ce585fb9f12895@nextdial.com.br> References: <28136f7b93ce45d9903e68a8416ff3c8@nextdial.com.br> <26d0ba3b25e246bcb6ce585fb9f12895@nextdial.com.br> Message-ID: <1526373749.1886.13.camel@de.loewenfelsen.net> Good morning, On Mon, 2018-05-14 at 16:54 -0300, subscription at nextdial.com.br wrote: > Hello Jake, > > Thanks for you reply. > > If I restart all listeners's connections would be droped (not only those > related to the droped mount). Nginx, for example, would reload the > configuration droping the server/location that don't exists anymore and > active the new ones. Icecast has not the same behaviour. > > Am I wrong? Is there any other way to do what I want to do? You are both right. The logic in Icecast is a bit different from general-purpose web servers (or exactly the same, depending on how you look at it). With a general-purpose web server an resource is created by creating the file on the file system. Config is then applied to that resource. With Icecast there is a different kind of resource, a source connection. It is "mounted" when the source connects. This is the point the resource is created. And it's destroyed on disconnect (like unlinking a flat file for a normal web server). At the point the resource is created (mounted) the config is applied to it. When you reload the config with the source running the resource is still there. Icecast tries to update it based on the new config. If there is none it just doesn't get updated. Your reference to nginx is a bit more complicated. nginx has more a focus on how you organize your namespace. You likely think of the "location" statement. Icecast has something similar, it's called (2.4.x) / (2.5.x). If you change those the effects are also active directly after reload. So, how do you remove the resource in Icecast?: Just log into the admin interface and select "Kill source" for the given source. It will disconnect the source client, therefore unmount the resource and destroy it. Little side node: There is no need in Icecast to configure mount points. It's just needed if you really need options that are not defaults (Icecast defaults, or defaults set in other parts of your configuration). With best regards, > ---------------------------------------- > De: "Jake" > Enviado: segunda-feira, 14 de maio de 2018 16:28 > Para: subscription at nextdial.com.br, "Icecast streaming server user > discussions" > Assunto: Re: [Icecast] Why current mount connection don't close after > remove from config and reload? > Well I am only guessing here, but I suspect if icecast works like other > daemons reload just reloads the config but doesn't terminate current > connections. You probably want /etc/init.d/icecast restart > > On 15 May 2018 12:35:39 AM NZST, "subscription at nextdial.com.br" > wrote: Hello, > > After removing a mount from the xml config file and reloading the Icecast > with the bellow command why it don't close the current mount connection? > > /etc/init.d/icecast2 reload > > There is another way? -- 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 un at aporee.org Tue May 15 11:35:09 2018 From: un at aporee.org (unosonic) Date: Tue, 15 May 2018 13:35:09 +0200 Subject: [Icecast] Parsing status-son.xsl In-Reply-To: <9975D294-5FAC-4199-A1C9-EA01FE0EC55C@riseup.net> References: <9975D294-5FAC-4199-A1C9-EA01FE0EC55C@riseup.net> Message-ID: <20180515113509.GA10443@aporee.org> hi, it's easy, try that as a start (untested!) it should display the # of listeners for your first source. see that status-json.xsl for all variables defined. Demo : icecast stats Listeners:
Damian: > Hi, > > I realise that the web is littered with posts and discussions concerning the topic of getting icecast stats from the xsl files (status-son.xsl) in the icecast web directory. As you may know, many of the solutions are outdated and example links are broken. I have limited knowledge of how to write my own javascript to get this info to display on my own website. Wondering if anyone can refer me to a currently working example or site that explains how to write my own JS to do this? Alternatively, I am happy to pay someone for their time or script. > > Damian > > - - - > I prefer to use encrypted email. > My public key fingerprint is 77CC 9087 0A92 F55D 75A3 660B 68F2 1FA9 B26E CAC7 > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From goudvanoudradio at gmail.com Sat May 19 09:32:47 2018 From: goudvanoudradio at gmail.com (Studio Goud van Oud) Date: Sat, 19 May 2018 11:32:47 +0200 Subject: [Icecast] Submitting stream Message-ID: Dear, I have a Icecast stream but i like to submit it to the Icecast directory. How must i do that? I hope you can help me. My stream is: http://server-23.stream-server.nl:8118 Stream name: Radio Goud van Oud Kind regards, Frans Horlings www.radiogoudvanoud.nl goudvanoudradio at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at ruecker.fi Sat May 19 16:53:55 2018 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B._R=c3=bccker?=) Date: Sat, 19 May 2018 16:53:55 +0000 Subject: [Icecast] Icecast 2.5 beta2 release Message-ID: We are pleased to announce Icecast 2.5 beta2 (2.4.99.2). This is a beta release and not recommended for production use. ## Downloads -?? Source: ??? http://downloads.xiph.org/releases/icecast/icecast-2.5-beta2.tar.gz -?? SHA256sum: ??? a83baf4ae3ee5c2822bcb4286b7438b01317ccb8387371922e9cd32fe1c453e8 -?? Packages: ??? https://build.opensuse.org/repositories/multimedia:xiph:beta ## New features - General: ??? * Add support for HTTP PUT, including chunked encoding support ??? * Improve TLS support including additional options, on the fly certificate ????? reload, RFC2817-mode, and TLS and non-TLS connections on same port ??? * Improve WebM support ??? * HTTP Keep-Alive support ??? * New error handling and better HTTP status codes in error cases ??? * Improved HTTP headers returned by Icecast ??? * Send `` tag content to YP servers - provides contact information ????? for directory operators - Web Interface/API: ??? * Add support for Opus metadata in web/stats interface ??? * List last played songs in web/stats interface ??? * Add support for xsl includes from the admin directory ??? * Add `protocol` to listener client stats XML ??? * Add `opmode` (operation mode) `strict` option ??? * Add support for config reload from the admin interface - Config: ??? * Add new tag `` with childs ``, ????? `` and `` ??? * Add new `` tag to specify the username ????? that is used for SHOUTcast sources ??? * Moved `` to the `` section ??? * Rename `` tag to `` ??? * Rename `` tag to `` ??? * Rename `ssl` tags (``, ``, ``) ????? to `tls` (``, ``, ``) ## Fixes - HTTP PUT now supports chunked encoding - HTTP PUT with `Expect: 100-Continue` now sends the `200` status as expected ? at the end of transmission, not right after the `100` - Fix login problems for admin user, if default mount had auth defined - Fix that in some cases stats JSON would be malformed - Fix that the JSON exposed listener details if queried with a specific mountpoint - Fix segfault on some bad opus streams - Fix segfaults due to empty strings in config - Fix fetching of streamlist (for relaying) from HTTP/1.1 servers - Fix information disclosure CVE that allowed to view the source ? of a xsl file by appending a `.` to it, when using Icecast on Windows ? (https://gitlab.xiph.org/xiph/icecast-server/issues/2248) ## Known issues - YP and m3u playlists do not use the `https` scheme for URLs when using TLS https://icecast.org/news/icecast-release-2_5-beta2/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From subscription at nextdial.com.br Wed May 23 01:46:05 2018 From: subscription at nextdial.com.br (subscription at nextdial.com.br) Date: Tue, 22 May 2018 22:46:05 -0300 Subject: [Icecast] Why "has fallen too far behind"? In-Reply-To: <28136f7b93ce45d9903e68a8416ff3c8@nextdial.com.br> References: <28136f7b93ce45d9903e68a8416ff3c8@nextdial.com.br> Message-ID: <6cbc7a93eb7c49178bed202a20b5cf9e@nextdial.com.br> Hello, We are seeing in Firebase this kind of errors: com.google.android.exoplayer2.upstream.HttpDataSource$InvalidResponseCodeExc eption: Response code: 401 So, after 12h trying to reproduce the error we saw what's happening. If the listener connection buffer due to anything, Icecast remove it's connection and log the item bellow: [2018-05-22 23:17:24] INFO source/send_to_listener Client 220977 (xxx.xxx.xxx.xxx) has fallen too far behind, removing My question is: Why Icecast need to do this? Why the client can't reconnect? The error 401 is when the client tries to reconnect and our auth deny? Best, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From subscription at nextdial.com.br Wed May 23 01:54:17 2018 From: subscription at nextdial.com.br (subscription at nextdial.com.br) Date: Tue, 22 May 2018 22:54:17 -0300 Subject: [Icecast] Icecast scale in 1 VPS with 2+ vCPUs In-Reply-To: <28136f7b93ce45d9903e68a8416ff3c8@nextdial.com.br> References: <28136f7b93ce45d9903e68a8416ff3c8@nextdial.com.br> Message-ID: Hello, We are using Icecast in a 2 vCPU VPS running Ubuntu 16 LTS. In our lastest test we saw in HTOP that Icecast was consuming about 94% in one CPU and, in the other one, ~57%. We had ~2400 simultaneous listeners 96Kbps AAC. Shouldn't Icecast scale both vCPUs? Is that the expected behaviour? Best, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at indexcom.com Wed May 23 02:42:00 2018 From: greg at indexcom.com (Greg Ogonowski) Date: Tue, 22 May 2018 19:42:00 -0700 Subject: [Icecast] Why "has fallen too far behind"? In-Reply-To: <6cbc7a93eb7c49178bed202a20b5cf9e@nextdial.com.br> References: <28136f7b93ce45d9903e68a8416ff3c8@nextdial.com.br> <6cbc7a93eb7c49178bed202a20b5cf9e@nextdial.com.br> Message-ID: <000001d3f23f$a334bc00$e99e3400$@indexcom.com> "The man with two clocks knoweth not the time." The audio source clock does not match the audio destination clock, and sooner or later, something needs to "give." This causes buffer under/over flows. The ICY protocol has no provision for timestamps which can be used to help circumvent this in player clients, if supported. HLS and DASH have this ability. /greg. StreamS From: Icecast On Behalf Of subscription at nextdial.com.br Sent: Tuesday, 22 May, 2018 18:46 To: icecast at xiph.org Subject: [Icecast] Why "has fallen too far behind"? Hello, We are seeing in Firebase this kind of errors: com.google.android.exoplayer2.upstream.HttpDataSource$InvalidResponseCodeExc eption: Response code: 401 So, after 12h trying to reproduce the error we saw what's happening. If the listener connection buffer due to anything, Icecast remove it's connection and log the item bellow: [2018-05-22 23:17:24] INFO source/send_to_listener Client 220977 (xxx.xxx.xxx.xxx) has fallen too far behind, removing My question is: 1. Why Icecast need to do this? 2. Why the client can't reconnect? 3. The error 401 is when the client tries to reconnect and our auth deny? Best, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at stationplaylist.com Wed May 23 04:58:16 2018 From: ross at stationplaylist.com (Ross Levis) Date: Wed, 23 May 2018 16:58:16 +1200 Subject: [Icecast] Why "has fallen too far behind"? In-Reply-To: <000001d3f23f$a334bc00$e99e3400$@indexcom.com> References: <28136f7b93ce45d9903e68a8416ff3c8@nextdial.com.br> <6cbc7a93eb7c49178bed202a20b5cf9e@nextdial.com.br> <000001d3f23f$a334bc00$e99e3400$@indexcom.com> Message-ID: <001801d3f252$aa7571e0$ff6055a0$@com> That answers question 1 but not 2 or 3. From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Greg Ogonowski Sent: Wednesday, 23 May 2018 2:42 p.m. To: subscription at nextdial.com.br; 'Icecast streaming server user discussions' Subject: Re: [Icecast] Why "has fallen too far behind"? "The man with two clocks knoweth not the time." The audio source clock does not match the audio destination clock, and sooner or later, something needs to "give." This causes buffer under/over flows. The ICY protocol has no provision for timestamps which can be used to help circumvent this in player clients, if supported. HLS and DASH have this ability. /greg. StreamS From: Icecast On Behalf Of subscription at nextdial.com.br Sent: Tuesday, 22 May, 2018 18:46 To: icecast at xiph.org Subject: [Icecast] Why "has fallen too far behind"? Hello, We are seeing in Firebase this kind of errors: com.google.android.exoplayer2.upstream.HttpDataSource$InvalidResponseCodeExc eption: Response code: 401 So, after 12h trying to reproduce the error we saw what's happening. If the listener connection buffer due to anything, Icecast remove it's connection and log the item bellow: [2018-05-22 23:17:24] INFO source/send_to_listener Client 220977 (xxx.xxx.xxx.xxx) has fallen too far behind, removing My question is: 1. Why Icecast need to do this? 2. Why the client can't reconnect? 3. The error 401 is when the client tries to reconnect and our auth deny? Best, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at indexcom.com Wed May 23 06:41:20 2018 From: greg at indexcom.com (Greg Ogonowski) Date: Tue, 22 May 2018 23:41:20 -0700 Subject: [Icecast] Why "has fallen too far behind"? In-Reply-To: <001801d3f252$aa7571e0$ff6055a0$@com> References: <28136f7b93ce45d9903e68a8416ff3c8@nextdial.com.br> <6cbc7a93eb7c49178bed202a20b5cf9e@nextdial.com.br> <000001d3f23f$a334bc00$e99e3400$@indexcom.com> <001801d3f252$aa7571e0$ff6055a0$@com> Message-ID: <000501d3f261$123c7d60$36b57820$@indexcom.com> The client should be able to reconnect, IF the client supports auto-reconnect. This is a client responsibility. IF for some reason, the client is not able to reconnect manually, something at the server level is preventing a reconnect. That should not be. Is that the case here? /g. StreamS From: Icecast On Behalf Of Ross Levis Sent: Tuesday, 22 May, 2018 21:58 To: 'Icecast streaming server user discussions' Subject: Re: [Icecast] Why "has fallen too far behind"? That answers question 1 but not 2 or 3. From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Greg Ogonowski Sent: Wednesday, 23 May 2018 2:42 p.m. To: subscription at nextdial.com.br ; 'Icecast streaming server user discussions' Subject: Re: [Icecast] Why "has fallen too far behind"? "The man with two clocks knoweth not the time." The audio source clock does not match the audio destination clock, and sooner or later, something needs to "give." This causes buffer under/over flows. The ICY protocol has no provision for timestamps which can be used to help circumvent this in player clients, if supported. HLS and DASH have this ability. /greg. StreamS From: Icecast > On Behalf Of subscription at nextdial.com.br Sent: Tuesday, 22 May, 2018 18:46 To: icecast at xiph.org Subject: [Icecast] Why "has fallen too far behind"? Hello, We are seeing in Firebase this kind of errors: com.google.android.exoplayer2.upstream.HttpDataSource$InvalidResponseCodeExc eption: Response code: 401 So, after 12h trying to reproduce the error we saw what's happening. If the listener connection buffer due to anything, Icecast remove it's connection and log the item bellow: [2018-05-22 23:17:24] INFO source/send_to_listener Client 220977 (xxx.xxx.xxx.xxx) has fallen too far behind, removing My question is: 1. Why Icecast need to do this? 2. Why the client can't reconnect? 3. The error 401 is when the client tries to reconnect and our auth deny? Best, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From cote2004-github at yahoo.com Tue May 29 12:34:10 2018 From: cote2004-github at yahoo.com (Eneas U de Queiroz) Date: Tue, 29 May 2018 09:34:10 -0300 Subject: [Icecast] [PATCH] Don't use deprecated API with openssl 1.1+ Message-ID: <20180529123410.16525-1-cote2004-github@yahoo.com> OpenSSL 1.1.0 has deprecated SSL_load_error_strings and SSL_library_init. Initialization is done automatically, so they're not needed with icecast. Fixes issue #2318 Signed-off-by: Eneas U de Queiroz --- src/tls.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/tls.c b/src/tls.c index 36edd86..6bd1aee 100644 --- a/src/tls.c +++ b/src/tls.c @@ -51,8 +51,10 @@ struct tls_tag { void tls_initialize(void) { +#if OPENSSL_VERSION_NUMBER < 0x10100000L SSL_load_error_strings(); /* readable error messages */ SSL_library_init(); /* initialize library */ +#endif } void tls_shutdown(void) { -- 2.16.1 From cote2004-github at yahoo.com Tue May 29 20:45:18 2018 From: cote2004-github at yahoo.com (Eneas U de Queiroz) Date: Tue, 29 May 2018 17:45:18 -0300 Subject: [Icecast] [PATCH v2 0/1] Don't use deprecated API with openssl 1.1+ In-Reply-To: <20180529123410.16525-1-cote2004-github@yahoo.com> References: <20180529123410.16525-1-cote2004-github@yahoo.com> Message-ID: <20180529204519.25000-1-cote2004-github@yahoo.com> I had to resend the patches, because I missed another deprecated call. Eneas U de Queiroz (1): Don't use deprecated API with openssl 1.1+ src/tls.c | 6 ++++++ 1 file changed, 6 insertions(+) -- 2.16.1 From cote2004-github at yahoo.com Tue May 29 20:45:19 2018 From: cote2004-github at yahoo.com (Eneas U de Queiroz) Date: Tue, 29 May 2018 17:45:19 -0300 Subject: [Icecast] [PATCH v2 1/1] Don't use deprecated API with openssl 1.1+ In-Reply-To: <20180529204519.25000-1-cote2004-github@yahoo.com> References: <20180529204519.25000-1-cote2004-github@yahoo.com> Message-ID: <20180529204519.25000-2-cote2004-github@yahoo.com> OpenSSL 1.1.0 has deprecated SSL_load_error_strings and SSL_library_init. Initialization is done automatically, so they're not needed with icecast. Fixes issue #2318 Signed-off-by: Eneas U de Queiroz --- src/tls.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/tls.c b/src/tls.c index 36edd86..e4688c5 100644 --- a/src/tls.c +++ b/src/tls.c @@ -51,8 +51,10 @@ struct tls_tag { void tls_initialize(void) { +#if OPENSSL_VERSION_NUMBER < 0x10100000L SSL_load_error_strings(); /* readable error messages */ SSL_library_init(); /* initialize library */ +#endif } void tls_shutdown(void) { @@ -71,7 +73,11 @@ tls_ctx_t *tls_ctx_new(const char *cert_file, const char *key_file, const char * if (!ctx) return NULL; +#if OPENSSL_VERSION_NUMBER < 0x10100000L method = SSLv23_server_method(); +#else + method = TLS_server_method(); +#endif ctx->refc = 1; ctx->ctx = SSL_CTX_new(method); -- 2.16.1 From phschafft at de.loewenfelsen.net Tue May 29 21:30:53 2018 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Tue, 29 May 2018 21:30:53 +0000 Subject: [Icecast] [PATCH v2 1/1] Don't use deprecated API with openssl 1.1+ In-Reply-To: <20180529204519.25000-2-cote2004-github@yahoo.com> References: <20180529204519.25000-1-cote2004-github@yahoo.com> <20180529204519.25000-2-cote2004-github@yahoo.com> Message-ID: <1527629453.2121.23.camel@de.loewenfelsen.net> Good evening, Thank you for your patches. Your patch is kind of what I was hoping for. :) On Tue, 2018-05-29 at 17:45 -0300, Eneas U de Queiroz wrote: > OpenSSL 1.1.0 has deprecated SSL_load_error_strings and > SSL_library_init. Initialization is done automatically, so they're not > needed with icecast. Fixes issue #2318 > [...] > +#if OPENSSL_VERSION_NUMBER < 0x10100000L > method = SSLv23_server_method(); > +#else > + method = TLS_server_method(); > +#endif Do you maybe also know when the return value became const? Maybe we could also have an #if for that? Would be very nice. Thank you for your work. I'm out of office from tomorrow till the 5th of June. Will try your patches (and apply them) when I'm back. 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 reddragoncharm at yahoo.com Thu May 31 08:28:41 2018 From: reddragoncharm at yahoo.com (john hamilton) Date: Thu, 31 May 2018 03:28:41 -0500 Subject: [Icecast] =?utf-8?q?=28no_subject=29?= Message-ID: <1527755329.OIwxfSFko3vLcOIwzfFxp8@mf-smf-ucb035c3> http://that.onwardsconsulting.org John Hamilton -------------- next part -------------- An HTML attachment was scrubbed... URL: