Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2023-01-03T10:08:01Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2441Icecast 2.5 beta 3 stops after 3 seconds2023-01-03T10:08:01ZMichelIcecast 2.5 beta 3 stops after 3 secondsThe ssl/https output stops after 3 seconds. The http output is okay. I have already report this on 2.4.
I use Debian 10 for OS.
Best regards,
MichelThe ssl/https output stops after 3 seconds. The http output is okay. I have already report this on 2.4.
I use Debian 10 for OS.
Best regards,
Michelhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2428issues Icecast version 2.5 beta32023-01-03T10:13:09ZMichelissues Icecast version 2.5 beta3Test on Debian 9
So far, the following issues / missing things:
- The Playlist does not display the time the song was played.
- Last song number cannot be set.
- It still does not display the song title in Opus and FLAC formats. (Tested...Test on Debian 9
So far, the following issues / missing things:
- The Playlist does not display the time the song was played.
- Last song number cannot be set.
- It still does not display the song title in Opus and FLAC formats. (Tested with MPD and RadioBOSS)
- /admin/version.xsl site: Could not parse XSLT file, Error code: f86b5b28-c1f8-49f6-a4cd-a18e2a6a44fd
- If the number of listeners reaches the number of allowed connections, then the admin page will display an error message, so it cannot be used either.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2423Allow setting the charset globally, not only on per-mount basis2021-11-15T18:41:48ZVadim UshakovAllow setting the charset globally, not only on per-mount basisHi! In my setup, I use a script that manages the sources dynamically, creating, starting and stopping mount points by user request. The icecast config is static, and all the sources share the same login/password. So no need to declare mo...Hi! In my setup, I use a script that manages the sources dynamically, creating, starting and stopping mount points by user request. The icecast config is static, and all the sources share the same login/password. So no need to declare mount points in icecast.xml in that case.
Unfortunately, IceCast uses the charset ISO8859-1 by default, and the only way to override it is declare mount point for each single source and specify `<charset>UTF-8</charset>` for each. This is extremely inconvenient.
I tried the following simple patch and seems to work. It allows to set the charset at the upper level so it takes effect for every mount point that doesn't explicitly override the value. If no charset is set at all, the default ISO8859-1 is used as the last resort.
Could you please merge it?
[global-charset.diff](/uploads/a1b7d890b0ea73d1d12fdf19b7b58209/global-charset.diff)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2416Is there a default listener-max-duration?2022-03-21T09:27:28ZcinderblockgamesIs there a default listener-max-duration?- Is there a default listener-max-duration?
- If so, is there a way to set it to infinite?
- If not, what is the maximum value supported?- Is there a default listener-max-duration?
- If so, is there a way to set it to infinite?
- If not, what is the maximum value supported?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2393playlist.log not supporting Unicode/UTF-8 chars2021-10-26T00:48:31ZMike Mackayplaylist.log not supporting Unicode/UTF-8 charsWhen a songs metadata contains Unicode/UTF-8 Chars, the playlist.log file is not writing them correctly. For example, when playing a track by Björk, the Artist name was correctly shown on the stream and in the main web GUI, however the p...When a songs metadata contains Unicode/UTF-8 Chars, the playlist.log file is not writing them correctly. For example, when playing a track by Björk, the Artist name was correctly shown on the stream and in the main web GUI, however the playlist.log file had "Bj?rk" instead.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2388Indefinite 100% CPU when disconnecting from SSL port when Icecast is running ...2021-01-23T08:17:31ZredactedscribeIndefinite 100% CPU when disconnecting from SSL port when Icecast is running inside a Podman container*UPDATE: This bug seems hard to track down and the solution as described below of spawning the Podman container as root rather than rootlessly doesn't actually work. It definitely seemed to be the fix last night, but I've now encountered...*UPDATE: This bug seems hard to track down and the solution as described below of spawning the Podman container as root rather than rootlessly doesn't actually work. It definitely seemed to be the fix last night, but I've now encountered the same high CPU usage problem that spawning as rootless was producing, but as root. Noteworthy is that I tested the same build process on the host system without containers, and the bug was no more, but judging how the bug has seemed to have has disappeared completely and then returned a few times, I'm not certain of the results. Leaving this report up as it could still lead to an answer.*
The easiest way for me to communicate the issue is through these steps:
- [Create a Let's Encrypt cert](https://certbot.eff.org/).
- Create `icecast.pem` using what Let's Encrypt produced: `fullchain.pem` + `privkey.pem`.
- Place `icecast.pem` into same dir as `Containerfile` and `entrypoint.sh` (attached files).
- [Install Podman](https://podman.io/getting-started/installation).
- As an unprivileged user, run: `podman build --force-rm -f Containerfile -t icecast`. This builds Icecast 2.4.4 from source with `--with-curl` and `--with-openssl` flags (`OpenSSL/1.1.1g` is what Alpine currently serves).
- Open ports `8000/tcp` and `8001/tcp` on the host if needed.
- Spawn an Icecast container (replace `<hostname>`):
```sh
podman run --rm --interactive --tty --publish 8000:8000 --publish 8001:8001 \
--env IC_HOSTNAME="<hostname>" \
--env IC_HTTP_PORT="8001" \
--env IC_HTTPS_PORT="8000" \
--env IC_LOG_LEVEL="4" \
--name icecast \
icecast
```
- To monitor Icecast's logs via the host, you can use `podman exec icecast tail /usr/local/var/log/icecast/access.log -f` and `podman exec icecast tail /usr/local/var/log/icecast/error.log -f`.
- Stream to the server's HTTPS port `8000` using a source client (in my case, Butt on Windows) with the default credentials.
- After connection, disconnect. `htop` on the host should now report 100% CPU for the container process, and reconnection via the source client should no longer be possible.
- Pressing `s` in `htop` on one of the two `icecast -c /usr/local/etc/icecast.xml` commands listed running at ~100% CPU, `strace` shows intense polling spam:
```sh
...
poll([{fd=7, events=POLLIN}], 1, 250) = 1 ([{fd=7, revents=POLLIN}])
read(7, read(7, read(7, read(7, ) = 1 ([{fd=7, revents=POLLIN}])
poll([{fd=7, events=POLLIN}], 1, 250) = 1 ([{fd=7, revents=POLLIN}])
read(7, "", 5) = 0
read(7, read(7, read(7, poll([{fd=7, events=POLLIN}], 1, 250) = 1 ([{fd=7, revents=POLLIN}])
...
```
For the other high CPU Icecast command, `strace` shows less spam:
```sh
...
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 300) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 300) = 0 (Timeout)
...
```
- With the container still running, running `podman exec icecast netstat -t` on the host shows Alpine waiting:
```sh
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 <hostname>:46372 <hostname>:8000 FIN_WAIT2
tcp 0 0 <hostname>:8000 <hostname>:46372 CLOSE_WAIT
netstat: /proc/net/tcp6: No such file or directory
```
It looks like the connection is never closed properly, as visiting `https://<hostname>:8000/admin/` and pressing `Kill Source` brings things back to normal. This is specifically confined to SSL as connecting to the HTTP port `8001` and then disconnecting has no adverse effects. Only the HTTPS port is affected.
~~The solution for me has been to spawn the Podman container as root rather than rootlessly. When doing so, Icecast doesn't get stuck in a loop waiting for the connection to drop after disconnection from HTTPS port (or whatever the exact issue is). Ideally, Icecast could function in a container run rootlessly as this is a major advantage of Podman's approach to containers over Docker's.~~
I am unsure if there is a bug on Podman's side (concerning container networking, or possible misconfiguration on my part), but I don't believe Icecast should be able to get stuck in this scenario producing 100% CPU indefinitely. Therefore, I have reported this here rather than to Podman.
Thanks.
Infos:
```
Icecast 2.4.4 (from source) running on Alpine inside the container
Podman 1.9.3
Fedora release 32 (Thirty Two)
Linux 5.6.19-300.fc32.x86_64
```
[icecast-indefinite-100_-cpu-bug-report.tar](/uploads/4840719fa9fe143617af35b9c78f6895/icecast-indefinite-100_-cpu-bug-report.tar)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2374Double quote in user agent causes malfomed log file2019-07-28T07:50:31ZNeil PalmerDouble quote in user agent causes malfomed log fileSome devices include a double quote character in their user agent.
The icecast log file quotes the user agent field, but does not escape any quotes inside of this, causing an invalid format.
Example:
> "Mozilla/5.0 (Linux; Android 5....Some devices include a double quote character in their user agent.
The icecast log file quotes the user agent field, but does not escape any quotes inside of this, causing an invalid format.
Example:
> "Mozilla/5.0 (Linux; Android 5.1; Alba 8" Build/LMY47I) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.91 Safari/537.36"https://gitlab.xiph.org/xiph/icecast-server/-/issues/2373Incorrect status code2020-10-15T16:20:55ZPhilipp SchafftIncorrect status codeIn case of 'mountpoint will not accept URL updates' and other admin errors Icecast might send incorrect HTTP status headers.
This happens at least in branch ph3-mdoule-client-tests.In case of 'mountpoint will not accept URL updates' and other admin errors Icecast might send incorrect HTTP status headers.
This happens at least in branch ph3-mdoule-client-tests.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2372Icecast 'locks up' on SIGHUP if there are duplicate listener-sockets in the c...2020-10-10T10:13:32ZThomas B. RückerIcecast 'locks up' on SIGHUP if there are duplicate listener-sockets in the configAs reported by 'szett' on IRC.
Excerp of the offending config file:
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</li...As reported by 'szett' on IRC.
Excerp of the offending config file:
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</listen-socket>
<!-- SOCKET FOR SOURCES -->
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</listen-socket>Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/23272.4.99.1 leaks filedescriptors?2020-02-25T08:58:43ZHugo2.4.99.1 leaks filedescriptors?Hi,
We've upgraded some of our production icecast servers to 2.4.99.1 this morning (from 2.4.2, because of the better TLS support). 1 one the 8 upgraded servers is expierencing problems which seem to be known as a "filedescriptor leak"....Hi,
We've upgraded some of our production icecast servers to 2.4.99.1 this morning (from 2.4.2, because of the better TLS support). 1 one the 8 upgraded servers is expierencing problems which seem to be known as a "filedescriptor leak". The server does not respond to new connections anymore, but seems to handle a lot of existing connections still fine. With netstat and lsof a lot of CLOSE_WAIT connections show up:
$ sudo lsof -np 28035 | wc -l
12895
$ sudo lsof -np 28035 | grep CLOSE_WAIT | wc -l
5973
The other 7 servers do not experience this problem (yet). The maximum amount of listeners today was about 6500 per server (on a number of channels).
Could it be that icecast is leaking filedescriptors somehow in situations that are not always triggered (since not all servers encounter this problem)?
All servers are running the same kernel; 4.1.39 and the installation is identical on all systems.
Any suggestions what could be done to debug this problem? It would be nice if we could reproduce this, but I have no clue what could cause this.
Regards,
Hugohttps://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/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/2223Icecast does not support HEAD requests2018-11-30T12:05:07ZOndra PelechIcecast does not support HEAD requestsalso reported on [Github](https://github.com/xiph/Icecast-Server/issues/2)
this makes transcodig in browser via javascript impossible
affects:
* [Aurora.js](https://github.com/audiocogs/aurora.js/issues/135)
* [Ampache](https://githu...also reported on [Github](https://github.com/xiph/Icecast-Server/issues/2)
this makes transcodig in browser via javascript impossible
affects:
* [Aurora.js](https://github.com/audiocogs/aurora.js/issues/135)
* [Ampache](https://github.com/ampache/ampache/issues/933)
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2188Fowarding of headers to authentication system not working2019-06-26T17:17:19ZSebastianFowarding of headers to authentication system not workingHey everyone,
i tried to forward some cookies or other headers to my authentication sytem. Unfortunately this does not work. The doc says the headers would be part of a POST but they don't appear. Can anyone confirm that?
```
<...Hey everyone,
i tried to forward some cookies or other headers to my authentication sytem. Unfortunately this does not work. The doc says the headers would be part of a POST but they don't appear. Can anyone confirm that?
```
<option name="headers" value="x-pragma,x-token"/>
<option name="header_prefix" value="ClientHeader."/>
```
```
<mount>
<mount-name>/example.ogg</mount-name>
<authentication type="url">
<option name="mount_add" value="http://auth.example.org/stream_start.php"/>
<option name="mount_remove" value="http://auth.example.org/stream_end.php"/>
<option name="listener_add" value="http://auth.example.org/listener_joined.php"/>
<option name="listener_remove" value="http://auth.example.org/listener_left.php"/>
<option name="username" value="user"/>
<option name="password" value="pass"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
<option name="timelimit_header" value="icecast-auth-timelimit:"/>
<option name="headers" value="x-pragma,x-token"/>
<option name="header_prefix" value="ClientHeader."/>
<option name="stream_auth" value="http://auth.example.org/source.php"/>
</authentication>
</mount>
```
Best Regards
SebastianThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2108Registrable URL handlers in connection.c instead of hardcoded list2018-07-16T09:09:26ZMarvin ScholzRegistrable URL handlers in connection.c instead of hardcoded listSuggested in TODO
>general registerable url-handlers in connection.c rather than hard-coded list
>(already getting unmaintainable)Suggested in TODO
>general registerable url-handlers in connection.c rather than hard-coded list
>(already getting unmaintainable)Thomas B. RückerThomas B. Rücker