Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2020-02-14T13:26:12Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2302Password extends into headers with BUTT shoutcast compatible source2020-02-14T13:26:12ZGary TunstallPassword extends into headers with BUTT shoutcast compatible sourceHi, I've found a bug in 2.4.3 (which if I understand correctly is the same as 2.4.2 for Linux).
Its a fairly minor one and is in part caused by the Source.
If you use BUTT (https://sourceforge.net/projects/butt/) to broadcast and setup a...Hi, I've found a bug in 2.4.3 (which if I understand correctly is the same as 2.4.2 for Linux).
Its a fairly minor one and is in part caused by the Source.
If you use BUTT (https://sourceforge.net/projects/butt/) to broadcast and setup an Icecast connection it works find. However if you set it up as a shoutcast connection and send to a shoutcast compatible port on icecast it fails.
Now the obvious question is why we'd use the "old" way of doing things. The answer is we are moving from shoutcast to icecast and a lot of our broadcasters still have the shoutcast settings and I'll like it to "just work" for them.
The problem is BUTT mixes its line endings, after the password there is just a /n but in the header lines it uses /r/n
In _handle_shoutcast_compatible in connection.c there is some code
```
/* Get rid of trailing \r\n or \n after password */
ptr = strstr (client->refbuf->data, "\r\r\n");
if (ptr)
headers = ptr+3;
else
{
ptr = strstr (client->refbuf->data, "\r\n");
if (ptr)
headers = ptr+2;
else
{
ptr = strstr (client->refbuf->data, "\n");
if (ptr)
headers = ptr+1;
}
}
```
Which unfortunately matches on the \r\n on the header, and misses the \n on the end of the password. So it uses the password a \n and the first line of the headers as the password, which fails and it rejects the connection.
For my purposes I've fix it by changing the code to:
```
/* Get rid of trailing \r\n or \n after password */
ptr = strstr (client->refbuf->data, "\n");
if (ptr)
{
headers = ptr+1;
while ( ( ptr > client->refbuf->data ) && ( ptr[-1]=='\r' ) )
{
ptr--;
}
}
```
So it finds the first \n and backtracks to remove any \r's
Obviously this is an edge case, in general people using BUTT will use icecast native connections, and most source client don't use mixed line endings. But I think my fixed version is probably more efficient on average anyway, so I think it should be safe to add.
I was going to try and submit a patch, but it looks like the code has moved on since the last version released, though even that didn't seem to use the latest changes at the time. So I'm not sure what is happening in that area. I'll leave this here and if its of any use then please include it. If you can shed more light on the evolution of the file and its worth it I can clone the latest version and test and if necessary make a patch for it.
Regards
GaryThomas B. RückerThomas B. Rückerhttps://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/2273Link error when compiling with cURL2017-10-05T10:40:40ZMarvin ScholzLink error when compiling with cURLIf cURL is detected and not explicitly disabled using `--without-curl` I get a linker error:
```
Undefined symbols for architecture x86_64:
"_icecast_curl_free", referenced from:
_auth_url_clear in auth_url.o
_event_get_u...If cURL is detected and not explicitly disabled using `--without-curl` I get a linker error:
```
Undefined symbols for architecture x86_64:
"_icecast_curl_free", referenced from:
_auth_url_clear in auth_url.o
_event_get_url in event_url.o
_event_url_free in event_url.o
_destroy_yp_server in yp.o
"_icecast_curl_initialize", referenced from:
_initialize_subsystems in main.o
_main in main.o
"_icecast_curl_new", referenced from:
_auth_get_url_auth in auth_url.o
_event_get_url in event_url.o
_yp_recheck_config in yp.o
"_icecast_curl_shutdown", referenced from:
_shutdown_subsystems in main.o
ld: symbol(s) not found for architecture x86_64
```Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2272Rename <mp3-metadata-interval> for clarity2017-10-05T10:40:40ZMarvin ScholzRename <mp3-metadata-interval> for clarityCurrently we have a mount specific config parameter called `mp3-metadata-interval`, which sets the metadata interval for ICY metadata, used for MP3 or AAC (and maybe some other formats). Therefore the name is misleading, especially for u...Currently we have a mount specific config parameter called `mp3-metadata-interval`, which sets the metadata interval for ICY metadata, used for MP3 or AAC (and maybe some other formats). Therefore the name is misleading, especially for users that stream AAC.
I would like to propose renaming it to `icy-metadata-interval` for clarity that this affects ICY and not just mp3.Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2270If relay with on-demand's source goes down, on_demand is no longer reported i...2020-10-11T11:40:22ZdonicsIf relay with on-demand's source goes down, on_demand is no longer reported in status-json.xsl when source returns.If you set up a relay with on-demand=1 in the relay settings, status-json.xsl will report the setting as on_demand=1. This is great, and helps with calculating total viewers on a source.
One thing I have found, though, is that if the so...If you set up a relay with on-demand=1 in the relay settings, status-json.xsl will report the setting as on_demand=1. This is great, and helps with calculating total viewers on a source.
One thing I have found, though, is that if the source goes down, the relay will stop reporting on_demand status-json.xsl. This continues even when the source comes back up. The only way to get on_demand reporting back is to restart the service.Thomas B. RückerThomas B. Rückerhttps://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/2263Add mime.types paths for other distros2020-10-11T14:45:20ZMarvin ScholzAdd mime.types paths for other distrosWe should add some more mime.types paths, seems the current one we have does not work on FreeBSD
and OS X uses a different one.
See [this](https://groups.google.com/forum/#!topic/golang-codereviews/fIw6mRzai4U) for some more paths that ...We should add some more mime.types paths, seems the current one we have does not work on FreeBSD
and OS X uses a different one.
See [this](https://groups.google.com/forum/#!topic/golang-codereviews/fIw6mRzai4U) for some more paths that seems to be usual.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2261Check if bitrate is missing on admin stats page2020-10-10T11:46:49ZMarvin ScholzCheck if bitrate is missing on admin stats pageAs asked by Jack Elliott on the mailing list:
> A RFE: would it be possible for the current stream bitrates to be
> displayed on stats.xsl ?As asked by Jack Elliott on the mailing list:
> A RFE: would it be possible for the current stream bitrates to be
> displayed on stats.xsl ?Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2259[PATCH] Master-Slave Aggregating Relay (multiple master setup)2017-10-05T10:40:40ZMarvin Scholz[PATCH] Master-Slave Aggregating Relay (multiple master setup)We got a pull-request on Github by [greenbender](https://github.com/greenbender):
> This pull request adds support for multiple Master-Slave relays. Something I am calling a Master-Slave Aggregating Relay.
>
> A couple of people have a...We got a pull-request on Github by [greenbender](https://github.com/greenbender):
> This pull request adds support for multiple Master-Slave relays. Something I am calling a Master-Slave Aggregating Relay.
>
> A couple of people have asked for this feature in the past and were referred to the Single-Broadcast Relay, which is OK provided you know the specific mountpoints that you want to relay ahead of time.
>
> If you are in a position where you want to relay mountpoints for more than one the master server, and one or more of the master servers adds and removes mountpoints dynamically or if you are unable to know what mountpoints are available ahead of time then this gives you the ability to aggregate all mountpoints for any numbers of master servers.
>
> Namespacing is also supported to prevent name clashes for mountpoints being relayed from different servers.
The patch can be found here:
```
https://github.com/xiph/Icecast-Server/pull/5.patch
```
For more information, see the [original Github Pull-Request](https://github.com/xiph/Icecast-Server/pull/5)!Icecast 2.5.2Thomas B. RückerThomas B. Rückerhttps://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/2255Invalid XML in Icecast statistics output due to lack of escaping2018-04-16T22:12:13ZThomas B. RückerInvalid XML in Icecast statistics output due to lack of escapingIcecast version 2.3.3-2ubuntu1.14.04.1 , when reporting statistics via API calls to http://%s:%d/admin/stats.xml, returns this invalid XML:
```
<icestats>
<source mount="/radio">
<Listeners>1</Listeners>
<listener>
<IP>23.2.9...Icecast version 2.3.3-2ubuntu1.14.04.1 , when reporting statistics via API calls to http://%s:%d/admin/stats.xml, returns this invalid XML:
```
<icestats>
<source mount="/radio">
<Listeners>1</Listeners>
<listener>
<IP>23.2.9.2</IP>
<UserAgent>Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12F70 [FBAN/FBIOS;FBAV/46.0.0.54.156;FBBV/18972819;FBDV/iPhone5,3;FBMD/iPhone;FBSN/iPhone OS;FBSV/8.3;FBSS/2; FBCR/AT&T;FBID/phone;FBLC/en_US;FBOP/5]</UserAgent>
<Connected>0</Connected>
<ID>2634887</ID>
</listener>
</source>
</icestats>
```
Note the unescaped &T; which is an undefined XML entity "T", and causes parsers to explode.
Expected behavior: text inside blocks should be html escaped or enclosed in a CDATA block, if I remember my XML correctly.
[Originally reported on github](https://github.com/xiph/Icecast-Server/issues/3) by [kenrestivo](https://github.com/kenrestivo)Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2254Replace autogen.sh with a simple wrapper around autoreconf2017-10-05T10:40:40ZMarvin ScholzReplace autogen.sh with a simple wrapper around autoreconfCurrently the autogen.sh script does a lot of stuff which is mostly not needed anymore,
given that autoreconf can do all of that and possibly even better.Currently the autogen.sh script does a lot of stuff which is mostly not needed anymore,
given that autoreconf can do all of that and possibly even better.Icecast 2.5.0Marvin ScholzMarvin Scholz