subscription at nextdial.com.br
2018-May-06 11:35 UTC
[Icecast] How to log querystring values?
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: <http://lists.xiph.org/pipermail/icecast/attachments/20180506/a052b506/attachment.html>
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)
subscription at nextdial.com.br
2018-May-06 13:23 UTC
[Icecast] How to log querystring values?
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" <lion at lion.leolix.org> Enviado: domingo, 6 de maio de 2018 09:30 Para: subscription at nextdial.com.br, "Icecast streaming server user discussions" <icecast at xiph.org> 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: <http://lists.xiph.org/pipermail/icecast/attachments/20180506/afeef368/attachment.html>
subscription at nextdial.com.br
2018-May-14 12:35 UTC
[Icecast] Why current mount connection don't close after remove from config and reload?
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: <http://lists.xiph.org/pipermail/icecast/attachments/20180514/ce9a6ccd/attachment.html>
Jake
2018-May-14 19:22 UTC
[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" <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: <http://lists.xiph.org/pipermail/icecast/attachments/20180515/a9473dd4/attachment.html>
subscription at nextdial.com.br
2018-May-23 01:46 UTC
[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: 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: <http://lists.xiph.org/pipermail/icecast/attachments/20180522/6fbe411d/attachment.html>
subscription at nextdial.com.br
2018-May-23 01:54 UTC
[Icecast] Icecast scale in 1 VPS with 2+ vCPUs
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: <http://lists.xiph.org/pipermail/icecast/attachments/20180522/23b1b995/attachment.html>
Hello, At a test VPS running Ubuntu 16.04 LTS I did this: sudo apt-get update sudo add-apt-repository ppa:certbot/certbot sudo apt-get install certbot sudo apt-get install icecast2 sudo certbot certonly --standalone -d domain.com cat cert.pem privkey.pem | sudo tee /etc/icecast2/icecast.pem sudo vi /etc/icecast2/icecast.xml <listen-socket> <port>8443</port> <ssl>1</ssl> </listen-socket> <ssl-certificate>/etc/icecast2/icecast.pem</ssl-certificate> sudo chown icecast2:icecast /etc/icecast2/icecast.pem sudo /etc/init.d/icecast2 restart After that, I have this at the log: [2018-08-12 01:47:07] INFO stats/_stats_thread stats thread started [2018-08-12 01:47:07] INFO main/main Icecast 2.4.2 server started [2018-08-12 01:47:07] INFO connection/get_ssl_certificate No SSL capability [2018-08-12 01:47:07] INFO yp/yp_update_thread YP update thread started I tried restart the VPS and a lot of things (change the order of the pem creation, etc), all with no success. What I am doing wrong? Best, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20180811/680c713f/attachment.html>
Hi, On 08/12/2018 02:04 AM, subscription at nextdial.com.br wrote:> Hello, > > At a test VPS running Ubuntu 16.04 LTS I did this: > > 1. sudo apt-get update > 2. sudo add-apt-repository ppa:certbot/certbot > 3. sudo apt-get install certbot >You'll need an additional step at this point, see below.> 1. sudo apt-get install icecast2 > 2. sudo certbot certonly --standalone -d domain.com > 3. cat cert.pem privkey.pem | sudo tee /etc/icecast2/icecast.pem > 4. sudo vi /etc/icecast2/icecast.xml > 5. <listen-socket> > <port>8443</port> > <ssl>1</ssl> > </listen-socket> > <ssl-certificate>/etc/icecast2/icecast.pem</ssl-certificate> > 6. sudo chown icecast2:icecast /etc/icecast2/icecast.pem > 7. sudo /etc/init.d/icecast2 restart > > > After that, I have this at the log: > > [2018-08-12 01:47:07] INFO stats/_stats_thread stats thread started > [2018-08-12 01:47:07] INFO main/main Icecast 2.4.2 server started > [2018-08-12 01:47:07] INFO connection/get_ssl_certificate No SSL > capability > [2018-08-12 01:47:07] INFO yp/yp_update_thread YP update thread started >This is because Debian (and Ubuntu, as they recycle the same packaging) refuse to compile Icecast (and other software) with openSSL support for political reasons.> What I am doing wrong >You didn't do anything wrong as such. You just didn't know that there are additional steps if you need TLS support. The official Xiph.org packages are built with openSSL support: https://wiki.xiph.org/Icecast_Server/Installing_latest_version_(official_Xiph_repositories) $ curl https://download.opensuse.org/repositories/multimedia:/xiph/xUbuntu_16.04/Release.key>/tmp/multimedia-obs.key$ gpg /tmp/multimedia-obs.key It should yield: pub rsa2048 2017-11-21 [SC] [expires: 2020-01-30] 0E313DB7936B4E76E720065B77EC2301F23C6AA3 uid multimedia OBS Project $ sudo apt-key add /tmp/multimedia-obs.key $ sudo sh -c "echo deb http://download.opensuse.org/repositories/multimedia:/xiph/xUbuntu_16.04/ ./ >>/etc/apt/sources.list.d/icecast.list" $ sudo apt-get update $ sudo apt-get install icecast2 Make sure it downloads the package from an OBS address and not from an ubuntu.com or mirror. (Newer versions like 18.04 require an explicit version or other tricks at the moment: sudo apt-get install icecast2/2.4.2-2 ) At this point your server should already be running the Xiph.org build of Icecast and port 8443 should answer to HTTPS. If you would prefer to listen to the standard port of 443, please follow these additional directions: http://lists.xiph.org/pipermail/icecast/2015-February/013198.html Under no circumstances you should try to reverse proxy Icecast 2.4.x - while one can make it mostly work, it is far from trivial to set things up in a way that will avoid most of the corner cases. Most famously, taking down your webserver. Cheers, Thomas
subscription at nextdial.com.br
2018-Aug-24 23:51 UTC
[Icecast] Client auth failed with ""
Hello, We are using url authentication and getting the item bellow at the log: [2018-08-24 23:26:05] INFO auth_url/url_add_listener client auth (http://127.0.0.1:8001/listener/add) failed with "" I put try/catch and reviewed all my code ensure always return a proper status and header error code, so what trigger this kind of error? Regards, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20180824/025af30d/attachment.html>