Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-06-16T20:52:48Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2310re-license to "GPL-2. with OpenSSL exception"2018-06-16T20:52:48ZJamiere-license to "GPL-2. with OpenSSL exception"The debian version of icecast2 doesn't ship with openssl, which means we can't embed streams in https pages without a mixed-content warning.
The debian maintainers report that [it is due to a openssl licensing conflict](https://bugs.deb...The debian version of icecast2 doesn't ship with openssl, which means we can't embed streams in https pages without a mixed-content warning.
The debian maintainers report that [it is due to a openssl licensing conflict](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744815#15) that could be resolved if icecast2 could be re-licensed to include an exception for openssl (among other options).
Is that option viable? Other options?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2309Can't connect to Icecast server from multiple tabs in Firefox2019-05-13T11:49:02ZugultopuCan't connect to Icecast server from multiple tabs in Firefox
## Steps to Reproduce
1. Open Firefox 50.1.0.
2. Connect to an Icecast mount point. The stream will start.
3. Open a new tab and try to connect to the same mount point. The connection won't be established.
4. Open a Private Window and t...
## Steps to Reproduce
1. Open Firefox 50.1.0.
2. Connect to an Icecast mount point. The stream will start.
3. Open a new tab and try to connect to the same mount point. The connection won't be established.
4. Open a Private Window and try to connect to the same mount point. The stream will start.
5. Open another tab in the Private Window and try to connect to the same mount point. The connection won't be established.
## Actual Results
Can't establish connection to an Icecast server from multiple tabs in Firefox.
## Expected Results
Establish connection to an Icecast server from multiple tabs in Firefox.
## Notes
1. The issue does not occur on Chrome. It is possible to connect to a mount point from as many tabs as you like.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2306Problem installing icecast repository2017-10-05T10:40:40ZradioonlinehdProblem installing icecast repositoryHello
I already tried to install the icecast repository in many ways, in my dedicated server CENTOS 6.8
But I could not do it.
You can see the error you're showing me.
I do not know if I'm doing it wrong, or there is a problem really.
I ...Hello
I already tried to install the icecast repository in many ways, in my dedicated server CENTOS 6.8
But I could not do it.
You can see the error you're showing me.
I do not know if I'm doing it wrong, or there is a problem really.
I ask you to help me as soon as possible, I am interested in updating Icecast 2.3.3-kh11 to Icecast 2.4.0-kh3
```
root@icecastsingle [~]# rpm --import http://download.opensuse.org/repositories/multimedia:/xiph/CentOS_6
error: http://download.opensuse.org/repositories/multimedia:/xiph/CentOS_6: key 1 not an armored public key.
```
Thank you very much.Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2305Icecast stream doesn't play properly using PotPlayer(64 bit, v 1.6.638912017-10-05T10:40:40ZkontrstIcecast stream doesn't play properly using PotPlayer(64 bit, v 1.6.63891When I play Otto's Baroque Music Radio, http://185.33.21.112:11037 no problem.
But get distortion WNYC AM (Icecast) http://am820.wnyc.org/wnycam.
When I play Otto's Baroque Music Radio, http://185.33.21.112:11037 no problem.
But get distortion WNYC AM (Icecast) http://am820.wnyc.org/wnycam.
Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2299Deadlock in SIGHUP signal handler2017-10-05T10:40:40ZVincent HuismanDeadlock in SIGHUP signal handlerI noticed that sometimes during reloading of the configuration, icecast would stop responding. This seems to be caused by mutex code in the signal handlers. It is possible to end up in a state where the mutex has been acquired by `global...I noticed that sometimes during reloading of the configuration, icecast would stop responding. This seems to be caused by mutex code in the signal handlers. It is possible to end up in a state where the mutex has been acquired by `global_lock()` (i.e. due to an incoming connection) but not yet released before the signal handler is called. Then, `global_lock()` is called again in the signal handler, but since it is already locked by the same thread, that call will block forever and the server stops handling new incoming requests.
### Affected versions:
* icecast2=2.4.0-1.1+deb8u1 (the current version in Debian Jessie)
* icecast2=2.4.2-1~bpo8+1 icecast2 binary only
I have encountered and reproduced this problem on icecast2=2.4.0-1.1+deb8u1. In trying to isolate the problem, I accidentally used the sources for icecast2=2.4.2-1~bpo8+1 and only copied the icecast2 binary over the already installed binary version, but that does not really change the outcome.
### Steps to reproduce:
* Simulate a lot of concurrent connection attempts
* While doing this, `kill -HUP icecast2`
### Expected result:
* Server handles those requests, reloads the config a couple of times
### Actual result:
* Server stops handling requests suddenly
```
# ab -t 20 -c 50 http://localhost:8000/ & for i in `seq 1 20`; do sleep 1; kill -HUP $(pidof icecast2); done[1] 2409
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
apr_socket_recv: Connection reset by peer (104)
Total of 15175 requests completed
[1]+ Exit 104 ab -t 20 -c 50 http://localhost:8000/
#
```
### Probable cause:
I added some extra logging to `_sig_hup()` and `global_lock()`, and an `usleep(100000)` to the latter after acquiring the mutex. In this setup, a simple call `curl http://localhost:8000/ & kill -HUP $(pidof icecast2)` is enough to trigger this problem every time, and it clearly shows the mutex being acquired due to the incoming connection, and an attempt to lock it again in the signal handler before it being released. The daemon then stops responding.
The underlying cause seems to be the attempt to acquire the global lock in the signal handling code. The same problem may occur in other scenarios as well. It looks to me that only `_sig_hup()` can trigger this bug.
### Proposed solution:
I'm not too much into the icecast code so I'm not really aware of any best/common practices yet, but I think an approach where the signal sets a global `global.reload_config = true` which is then handled in the main event loop (outside the signal handler) would do the trick, much the same way as `_sig_die()` works.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2293High CPU usage on macOS Sierra2017-10-05T10:40:40ZSanderHigh CPU usage on macOS SierraI am experiencing high CPU (95%) on macOS when connecting to a local Icecast server. The high CPU starts when a source connects, and remains even afer sources are no longer connected, until I restart the server.
Versions tested:
1. hom...I am experiencing high CPU (95%) on macOS when connecting to a local Icecast server. The high CPU starts when a source connects, and remains even afer sources are no longer connected, until I restart the server.
Versions tested:
1. homebrew 2.4.2 with my custom config,
2. compiled from source 2.4.3 with default config.
When running within a virtualbox Ubuntu server instance, Icecast is behaving nicely.
I've ran a Instruments time + counter trace, data is available from https://dl.dropboxusercontent.com/u/70903/Icecast%20Instruments.zip and attached to this ticket.
It seems to show that 97% of the time fserve_client_waiting is doing a poll, not sure if this is normal I'm not experienced with this subject. 1 every millisecond if I'm reading the counter correctly.
[12:28] <+tbr> I guess this is something we should definitely look into.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2292Relay slave fails to connect over Amazon ELB2018-11-10T12:48:22ZRaz YalovRelay slave fails to connect over Amazon ELBTrying to configure a slave Icecast server through an Amazon Elastic Load Balancer (ELB), the socket never connects.
Log shows this error:
WARN slave/update_from_master Relay slave failed to contact master server to fetch stream list...Trying to configure a slave Icecast server through an Amazon Elastic Load Balancer (ELB), the socket never connects.
Log shows this error:
WARN slave/update_from_master Relay slave failed to contact master server to fetch stream list
using strace it seems like the connection never establishes on the socket's opening level, but there is not description of the exact error.
Replacing the load balancer DNS with the IP of one of the servers that are behind the ELB does seems to work.
login as the icecast user I was able to verify that the same information does work directly via telnet and curl. Only the icecast connection fails through the ELB.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2284Icecast segfaults on startup and shutdown2018-07-02T00:38:16ZBrendonIcecast segfaults on startup and shutdownUsing the latest 2.4.3 with SSL on Debian 8 x64 (happens with SSL disabled as well). Running icecast using daemontools. This also happened with 2.4.2 being started with upstart. Startup script is:
```
exec /usr/local/bin/icecast -c /etc...Using the latest 2.4.3 with SSL on Debian 8 x64 (happens with SSL disabled as well). Running icecast using daemontools. This also happened with 2.4.2 being started with upstart. Startup script is:
```
exec /usr/local/bin/icecast -c /etc/icecast/icecast.xml
```
I've noticed that the icecast process segfaults on both startup and shutdown.
Shutdown:
```
Aug 24 14:50:01 ngradio-staging kernel: [80171.821413] icecast[16264]: segfault at 48 ip 000000000040fa8e sp 00007f2af4087dd0 error 4 in icecast[400000+34000]
```
Startup:
```
Aug 24 14:41:02 ngradio-staging kernel: [79632.697742] icecast[14984]: segfault at 0 ip 00007fc773ea3c3a sp 00007fc775798e18 error 4 in libc-2.19.so[7fc773e22000+1a2000]
```
Observations:
- Happens 100% of the time the process is stopped.
- Happens nearly 100% of the time the process is started, and at times can happen 5-10 times before the icecast process will start. Sometimes I can't get the process to start at all when I'm starting it manually via the cli (tried 10-20 times then gave up).
- Happens with the liquidsoap processes trying to connect and with liquidsoap completely down.
- Nothing seems to be correlated with these segfaults, nor with this happening once or multiple times before the process ultimately starts.
- I don't get a segfault on startup when running Icecast via valgrind, but I do when running directly on the cli, via strace, or via daemontools.
- Sometimes if I start / restart icecast a bunch via daemontools, I can't get the process to start up at all. A reboot seems to be the only thing that helps.
I uploaded my Icecast config and some valgrind output in #2283. This is the tail end of the strace output:
```
munmap(0x7f23bacb1000, 4096) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
write(7, "[2016-08-24 14:53:33] INFO conn"..., 118) = 118
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
write(7, "[2016-08-24 14:53:33] INFO conn"..., 836) = 836
poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, 300 <unfinished ...>
+++ killed by SIGSEGV +++
```
Let me know if I can provide any other info. As of right now, this is simply a nuisance, but without daemontools restarting the process over and over until it finally does start up, this would probably be a blocker.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2283Streaming over SSL disconnects2020-02-26T00:04:46ZBrendonStreaming over SSL disconnectsI reported this via IRC but wanted to make sure a proper bug report gets filed before moving on.
I'm building a streaming radio service for Newgrounds.com. More than one application has an embedded radio player and these applications ar...I reported this via IRC but wanted to make sure a proper bug report gets filed before moving on.
I'm building a streaming radio service for Newgrounds.com. More than one application has an embedded radio player and these applications are all served over SSL.
In order to avoid mixed content warnings, I built Icecast 2.4.3 with SSL support so I could get status info and serve the stream over SSL as well.
(None of the Debian or Ubuntu packages have been built with SSL yet for some reason.)
I'm using Debian 8 x64. libssl is 1.0.1t (which is the latest 1.0.1 LTS version). liquidsoap 1.1.1 is the source and connects to Icecast via port 80 on localhost (both liquidsoap and icecast are on the same VM).
I have six mounts configured all the same. liquidsoap is re-encoding the mp3s at a constant bitrate of 128k. I've uploaded a stripped down Icecast config.
Here is what happens: normally, streaming over SSL works perfectly fine. But sometimes, either right at stream start or at some seemingly random amount of time later, one of the mounts becomes "corrupted." The web player (using a simple <audio> tag) quickly buffers and disconnects. VLC reconnects and gets disconnected over and over.
I've tested this on my local network over wifi using the web player, VLC, and iTunes, and with ServeStream on Android over cellular. All same result.
If I connect to the stream via port 80, I do not get disconnected. I get disconnected from the stream ONLY when streaming over SSL and ONLY when the mount becomes corrupted.
Observations:
- This happens on every mount seemingly at random, but it seems that only ONE mount becomes corrupted at a time.
- Doesn't seem to be triggered by any one song, a track change, or anything else station related that I can find.
- Happens if I use ogg or mp3.
- Shutting down the liquidsoap instance for the corrupted mount, waiting a minute or so (a quick restart doesn't seem to fix it) and then restarting liquidsoap seems to resolve the issue (at least temporarily).
- Nothing in the logs that I can see, even with debug logging on:
[2016-08-21 20:30:08] DBUG stats/modify_node_event update "/electronic" listeners (1)
[2016-08-21 20:30:08] DBUG format/format_check_http_buffer processing pending client headers
[2016-08-21 20:30:08] DBUG client/client_send_bytes Client connection died
[2016-08-21 20:30:08] DBUG source/source_main Client removed
[2016-08-21 20:30:08] INFO source/source_main listener count on /electronic.mp3 now 0
These cycle over and over again as the client disconnects and reconnects. I can find nothing else in any of the logs on the system.
- This happens on both staging and production which is on two separate servers.
I was asked to run Icecast using valgrind. We saw lots of SSL errors, so one possible issue could be a buggy system libssl (which I do not think is the case at this point). I even got the latest OpenSSL 1.0.2h built and then built Icecast against that to rule out 1.0.1t causing a bunch of errors.
I will upload the Valgrind output for both 1.0.1t and 1.0.2h.
I simply started Icecast and then shut it down via ctrl-c. This was NOT running while experiencing a corrupted mount.
That's about as much information as I think I have at this point. I have decided to abandon using SSL for the streams as it simply does not seem to be production ready at this point. This will cause mixed content errors in our applications, but streaming over http seems much more stable.
I'd be happy to help provide more information if requested.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2277Have status.xsl show the html5 in-line player also for audio/mpeg2017-10-05T10:40:40ZDaniel LublinHave status.xsl show the html5 in-line player also for audio/mpegThis is commonly supported now days, any reason not to show it?
This is commonly supported now days, any reason not to show it?
Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2269Allow certificate rotation2018-06-15T20:37:13ZFinnAllow certificate rotationI'd like to re-issue my SSL certs somewhat frequently and have Icecast reload them without kicking off all my users. Perhaps with a SIGHUP?
Specifically, I'm using Let's Encrypt which automatically re-issues certs every 90 or so days, a...I'd like to re-issue my SSL certs somewhat frequently and have Icecast reload them without kicking off all my users. Perhaps with a SIGHUP?
Specifically, I'm using Let's Encrypt which automatically re-issues certs every 90 or so days, and it'd be nice to be able to set Icecast on a cronjob to re-read them after they get reissued.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2265Malformed 'max-listeners' in icecast.xml causes Segmentation Fault2017-10-05T10:40:40Zicy2005Malformed 'max-listeners' in icecast.xml causes Segmentation FaultHi all!
How to reproduce:
1. Put the following under <icecast><mount>:
<max-listeners/>
2. Run /usr/bin/icecast2 -c /etc/icecast2/icecast.xml
3. Confirm if it crashes with "Segmentation Fault"
Hotfix:
1. Change <max-listeners/...Hi all!
How to reproduce:
1. Put the following under <icecast><mount>:
<max-listeners/>
2. Run /usr/bin/icecast2 -c /etc/icecast2/icecast.xml
3. Confirm if it crashes with "Segmentation Fault"
Hotfix:
1. Change <max-listeners/> to a value, e.g.:
<max-listeners>100</max-listeners>
Thanks!Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2258Absolute paths when relaying2018-06-15T20:47:52ZmschmidAbsolute paths when relayingI've set up a couple of relays that were/still are properly running under icecast 2.3.2 with its separate mount point configuration, while they do not work under 2.4.0 and later.
The problem seems to be tied to how the client's requests ...I've set up a couple of relays that were/still are properly running under icecast 2.3.2 with its separate mount point configuration, while they do not work under 2.4.0 and later.
The problem seems to be tied to how the client's requests are interpreted. On the newer version it seems to be forbidden to request the full path, while the old did support this. But relays always create the full path in the links.
the server'n name is 'mediaserv'.
the paths are configured like this (debian defaults, no chroot):
<basedir>/usr/share/icecast2</basedir>
<logdir>/var/log/icecast2</logdir>
<webroot>/usr/share/icecast2/web</webroot>
<adminroot>/usr/share/icecast2/admin</adminroot>
a relay example is:
<relay>
<server>mms-live.online.no</server>
<port>80</port>
<mount>/p4_norge_mp3_hq</mount>
<local-mount>/p4</local-mount>
<on-demand>1</on-demand>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
</relay>
The content of
http://mediaserv:8000/usr/share/icecast2/web/p4.m3u
is:
http://mediaserv:8000/usr/share/icecast2/web/p4
which does no longer work.
When I reduce it to http://mediaserv:8000/p4, it's working perfectly.
Shouldn't all the links be relative?
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2257Icecast hangs after several hours running2017-10-05T10:40:40ZDaniel LafraiaIcecast hangs after several hours runningI have a couple of Icecast servers at Digital Ocean used as a relay to our main Icecast server at AWS. For some reason the edge server (the one receiving connections from end users) hangs completely.
I had to setup Supervisord to do an ...I have a couple of Icecast servers at Digital Ocean used as a relay to our main Icecast server at AWS. For some reason the edge server (the one receiving connections from end users) hangs completely.
I had to setup Supervisord to do an HTTP request to status.xsl to determine if it's up, so it can be restarted when it happens (status.xsl request times out). Actually this happens both servers, same behavior hanging every 1 or 2 days or so.
This is not a busy streaming server (about 400 listeners peak each). When it hangs sometimes it's not on peak hours, I've seen it happening early morning.
Error_log stops longing when it happens, so there's not much information there (using loglevel 3).
This icecast server is running in a docker container, just like the main server. I'm starting this docker image with ulimit 1024:1024 for nofile.
How can I provide you with more info so we can see if this is a bug?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2256Icecast 2.4.2 hangs after several hours running2017-10-05T10:40:40ZDaniel LafraiaIcecast 2.4.2 hangs after several hours runningI have a couple of Icecast servers at Digital Ocean used as a relay to our main Icecast server at AWS. For some reason the edge server (the one receiving connections from end users) hangs completely.
I had to setup Supervisord to do an ...I have a couple of Icecast servers at Digital Ocean used as a relay to our main Icecast server at AWS. For some reason the edge server (the one receiving connections from end users) hangs completely.
I had to setup Supervisord to do an HTTP request to status.xsl to determine if it's up, so it can be restarted when it happens (status.xsl request times out). Actually this happens both servers, same behavior hanging every 1 or 2 days or so.
This is not a busy streaming server (about 400 listeners peak each). When it hangs sometimes it's not on peak hours, I've seen it happening early morning.
Error_log stops longing when it happens, so there's not much information there (using loglevel 3).
This icecast server is running in a docker container, just like the main server. I'm starting this docker image with ulimit 1024:1024 for nofile.
How can I provide you with more info so we can see if this is a bug?Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2248File extension check ignores trailing characters2017-10-05T10:40:40ZMarvin ScholzFile extension check ignores trailing charactersThe `util_check_valid_extension` function will ignore any characters after a matched file extension, so that `xsl`, `xslt` and `xslfoooo` will all return `XSLT_CONTENT`, even though the last one really should not.
Additionally there is ...The `util_check_valid_extension` function will ignore any characters after a matched file extension, so that `xsl`, `xslt` and `xslfoooo` will all return `XSLT_CONTENT`, even though the last one really should not.
Additionally there is a check for `htm` and after that another one for `html`, but the first check will always match even in the case of html, so that code is actually useless and never execute.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2247XSLs are returned in plaintext if trailing dot is appended to the URL (Window...2018-04-16T22:12:13ZMarvin ScholzXSLs are returned in plaintext if trailing dot is appended to the URL (Windows only)If requesting an xsl file, anyone can get a unprocessed version of that file, possibly exposing internal information to the user, by appending a dot to the requested filename:
```
http://localhost:8000/status.xsl.
```
Only Windows is...If requesting an xsl file, anyone can get a unprocessed version of that file, possibly exposing internal information to the user, by appending a dot to the requested filename:
```
http://localhost:8000/status.xsl.
```
Only Windows is affected. This is due to the way the Windows API handles filenames, as it strips the trailing dot and will assume status.xsl instead of the version with the trailing dot.
*Unix and Linux builds were never affected.*
(See CVE-2005-0837 and #635)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2245Move TLS options out of <paths>2018-06-15T20:50:30ZPhilipp SchafftMove TLS options out of <paths>The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2231process hangs after HUP signal2023-05-08T09:49:13Zhk_netprocess hangs after HUP signalwe got icecast 2.4.2 running fine, but some times after several HUP signals for logrotation the process hangs, no more listening on its tcp-socket nor logging anything.
stopping and restarting helps to get the stream working again, but ...we got icecast 2.4.2 running fine, but some times after several HUP signals for logrotation the process hangs, no more listening on its tcp-socket nor logging anything.
stopping and restarting helps to get the stream working again, but we do have no clue how to find the issue causing this behavior.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2226Adding <mount-title> for mountpoints2018-11-10T15:54:39ZvtangerAdding <mount-title> for mountpointsAs there are a number of semi-defective clients which do not transmit a description/title as well as people out there who cannot reliably enter the display title into their client configuration, such an override-option in the configurat...As there are a number of semi-defective clients which do not transmit a description/title as well as people out there who cannot reliably enter the display title into their client configuration, such an override-option in the configuration would come handy. Thomas B. RückerThomas B. Rücker