Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2022-02-28T11:17:41Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2409The <no-mount> flag should be visible at the status page2022-02-28T11:17:41ZPhilipp SchafftThe <no-mount> flag should be visible at the status pageThe `<no-mount>` flag should be visible at the status page. At least the player and the playlist links should be removed.The `<no-mount>` flag should be visible at the status page. At least the player and the playlist links should be removed.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2408Rename <no-mount>2022-02-28T10:58:49ZPhilipp SchafftRename <no-mount>The config option `<no-mount>` should be renamed to have some better name.
One of the suggestions was `<allow-direct-access>` (which has inverted logic).The config option `<no-mount>` should be renamed to have some better name.
One of the suggestions was `<allow-direct-access>` (which has inverted logic).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2407status-json.xsl can return invalid JSON at startup2021-04-15T12:13:43ZFunctionstatus-json.xsl can return invalid JSON at startup[I wrote this issue last year](https://github.com/xiph/Icecast-Server/issues/38) but on the GitHub repo. I thought i'd post it here in hopes that someone sees it :)
The page may return this code right after starting Icecast:
```json
{"...[I wrote this issue last year](https://github.com/xiph/Icecast-Server/issues/38) but on the GitHub repo. I thought i'd post it here in hopes that someone sees it :)
The page may return this code right after starting Icecast:
```json
{"icestats":"server_start":"Sat, 03 Oct 2020 15:45:30 +0200","server_start_iso8601":"2020-10-03T15:45:30+0200","dummy":null}}
```
(notice the double closing `}`)
This is invalid JSON, and as i couldn't find a difference between 2.4.4 (which i'm using) and the latest version of the file in master i strongly assume this bug is present in all recent versions. Please correct me if i'm wrong.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2406Icecast SSL stream information2022-04-20T09:19:24ZAlain SeysIcecast SSL stream informationNot realy a issue rather a question we have a icecast server if we listen (vlc)to the http stream we can get the current track information if we listen to the https stream(vlc) we only can hear the stream but no track information is serv...Not realy a issue rather a question we have a icecast server if we listen (vlc)to the http stream we can get the current track information if we listen to the https stream(vlc) we only can hear the stream but no track information is served.
is there a way to also give the track information trough ssl ?
on our website we use a php script to get the trackinformation from a https stream but in vlc we cant get it to work.
please advise mehttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2405Recovering from fallback directs to wrong mount2021-05-08T14:13:53ZLauri HeikkiläRecovering from fallback directs to wrong mountDon't know should one re-open old issue https://gitlab.xiph.org/xiph/icecast-server/-/issues/642 or not, but here's a new one...
One has two mounts (/mount_a and mount_b) with the same fallback mount<br>
-> The sources for both relayed ...Don't know should one re-open old issue https://gitlab.xiph.org/xiph/icecast-server/-/issues/642 or not, but here's a new one...
One has two mounts (/mount_a and mount_b) with the same fallback mount<br>
-> The sources for both relayed mounts (/remote_mount_a and /remote_mount_b) go down<br>
-> All listeners get directed to /backup mount<br>
-> Both relayed sources recover<br>
-> All listeners get directed to single mount, for example /mount_a, even though they were listening /mount_b before
```
<relay>
<server>a.remote.server.com</server>
<mount>/remote_mount_a</mount>
<local-mount>/mount_a</local-mount>
</relay>
<mount type="normal">
<mount-name>/mount_a</mount-name>
<fallback-mount>/backup</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
<relay>
<server>remote.server.com</server>
<mount>/remote_mount_b</mount>
<local-mount>/local_mount_b</local-mount>
</relay>
<mount type="normal">
<mount-name>/mount_b</mount-name>
<fallback-mount>/backup</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
<relay>
<server>b.remote.server.com</server>
<mount>/remote_backup</mount>
<local-mount>/backup</local-mount>
<on-demand>1</on-demand>
</relay>
```Icecast 2.5.0https://gitlab.xiph.org/xiph/icecast-server/-/issues/2404Issues in log file dublicate items since start of 20212021-01-04T20:47:54ZHans-Georg AlthoffIssues in log file dublicate items since start of 2021I have figured out, that user access is repeating the same data several times since the beginning of the year.
Usual the lines are ordered by time. Now I can see, that ip adresses are repeating with the same date and time.
This is corr...I have figured out, that user access is repeating the same data several times since the beginning of the year.
Usual the lines are ordered by time. Now I can see, that ip adresses are repeating with the same date and time.
This is corrupting my programm[access.log.old](/uploads/10f05b8ae9d6960d4a921d4654ab6e9c/access.log.old), which I use to analyse the data.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2402Auth url webhooks not working2020-11-14T16:56:42ZJohn MidsonAuth url webhooks not workingHi guys,
Sorry if I'm missing something obvious, but I really can't make authentication url working.
I have Icecast configs:
```
<mount>
<mount-name>/aac_high</mount-name>
<authentication type="url">
<option...Hi guys,
Sorry if I'm missing something obvious, but I really can't make authentication url working.
I have Icecast configs:
```
<mount>
<mount-name>/aac_high</mount-name>
<authentication type="url">
<option name="listener_add" value="http://localhost:3000/api/v1/listeners/add"/>
<option name="listener_remove" value="http://localhost:3000/api/v1/listeners/remove"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
</authentication>
</mount>
```
By calling `/aac_hight` I got 401 despite server is configured to return correct header:
```
$ curl http://localhost:8000/aac_high
<?xml version="1.0"?>
<report xmlns="http://icecast.org/specs/reportxml-0.0.1" version="0.0.1"><incident><state definition="25387198-0643-4577-9139-7c4f24f59d4a"><text>You need to authenticate</text></state></incident><extension application="http://icecast.org/specs/legacy-icestats"><icestats xmlns="http://icecast.org/specs/legacystats-0.0.1"><modules/></icestats></extension></report>
```
In Icecast's `error.log` I'm getting:
```
[2020-11-05 11:44:02] INFO auth/queue_auth_client auth on /aac_high has 1 pending
[2020-11-05 11:44:02] INFO auth_url/url_add_client client auth (http://localhost:3000/api/v1/listeners/add) failed with ""
[2020-11-05 11:44:02] WARN reportxml/reportxml_database_build_report No matching definition for "25387198-0643-4577-9139-7c4f24f59d4a"
```
So, looks like it is trying to reach `http://localhost:3000/api/v1/listeners/add` but in server logs I don't see any incoming request at all.
Callback on localhost:3000 working fine:
```
$ curl -v -X POST http://localhost:3000/api/v1/listeners/add
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 3000 (#0)
> POST /api/v1/listeners/add HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< icecast-auth-user: 1
< Server: Dominion
< Date: Thu, 05 Nov 2020 12:19:24 GMT
< Connection: keep-alive
< Content-Length: 0
<
* Connection #0 to host localhost left intact
```
Icecast is built from master branch, additional info:
```
$ ./icecast -v
Icecast 2.4.99.2
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
```
Will appreciate any hint what is going wrong. Thanks!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2399Crash Icecast 2.4.4 on CentOS 7.52020-10-19T17:28:24ZMediaKCrash Icecast 2.4.4 on CentOS 7.5Linked from previous report `https://gitlab.xiph.org/xiph/icecast-server/-/issues/2344`
My radio stream service exits on minimal load.
I'm using Icecast 2.4.4
OpenSSL 1.0.2k-fips 26 Jan 2017
On CentOs 7.8
WHM/CPANEL: v90.0.15
`Oct 18 ...Linked from previous report `https://gitlab.xiph.org/xiph/icecast-server/-/issues/2344`
My radio stream service exits on minimal load.
I'm using Icecast 2.4.4
OpenSSL 1.0.2k-fips 26 Jan 2017
On CentOs 7.8
WHM/CPANEL: v90.0.15
`Oct 18 02:18:33 server1 kernel: traps: icecast[16512] general protection ip:7f2327a88c09 sp:7ffdab32ab80 error:0 in libssl.so.1.0.2k[7f2327a5c000+67000]
`
With added errors
`Oct 18 02:18:33 server1 systemd: icecast.service: main process exited, code=killed, status=11/SEGV
Oct 18 02:18:33 server1 systemd: Unit icecast.service entered failed state.
Oct 18 02:18:33 server1 systemd: icecast.service failed.`
How can this be resolved?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2398Handling of GET request on admin/ should be updated2020-10-15T15:24:33ZPhilipp SchafftHandling of GET request on admin/ should be updatedCurrently GET request are handled alike POST request. This should be changed to the following:
In operation mode `legacy`: \
Keep as is.
In operation mode `normal`: \
Write a warning about such clients.
In operation mode `strict`: \
R...Currently GET request are handled alike POST request. This should be changed to the following:
In operation mode `legacy`: \
Keep as is.
In operation mode `normal`: \
Write a warning about such clients.
In operation mode `strict`: \
Reject the request.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2396Unifiy <xsl:output>-settings for web/ and admin/2020-10-09T16:38:28ZPhilipp SchafftUnifiy <xsl:output>-settings for web/ and admin/`<xsl:output>`-settings must match web/ and admin/ as they share some templates.`<xsl:output>`-settings must match web/ and admin/ as they share some templates.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2395Missing files in share/admin after make install2020-10-09T16:38:28ZGilouMissing files in share/admin after make installA few of the newer xsl files for admin are missing after make install:
```
~/icecast-server$ diff -r admin/ /usr/local/share/icecast/admin/ | grep -v Makefile
Only in admin/: dashboard.xsl
Only in admin/: fallbacks.xsl
Only in admin/incl...A few of the newer xsl files for admin are missing after make install:
```
~/icecast-server$ diff -r admin/ /usr/local/share/icecast/admin/ | grep -v Makefile
Only in admin/: dashboard.xsl
Only in admin/: fallbacks.xsl
Only in admin/includes: player.xsl
Only in admin/includes: playlist.xsl
Only in admin/: showlog.xsl
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2394Include libshout release 2.4.4 on website2020-10-02T20:20:37ZPhilipp SchafftInclude libshout release 2.4.4 on websiteThe following libshout release should distributed on the mirrors and then included in the website:
```
ddc44d4db0193471b1a61d41e8ec975a021da4f5af657716ecbb1eaf95231e03ac44036148f0d5bd897ba5c03f075fd67017fecfccebb4f11be56375c0e5c088 lib...The following libshout release should distributed on the mirrors and then included in the website:
```
ddc44d4db0193471b1a61d41e8ec975a021da4f5af657716ecbb1eaf95231e03ac44036148f0d5bd897ba5c03f075fd67017fecfccebb4f11be56375c0e5c088 libshout-2.4.4.tar.gz
7273d5e8da3ad10e6fc754663df5b56e8058a41f libshout-2.4.4.tar.gz
```Ralph GilesRalph Gileshttps://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/2390status-json with fallback-mount2020-08-31T15:48:47ZIgor dWstatus-json with fallback-mountI have icecast 2.4.4 with win2016 server. I'm using a fallback-mount. When the fallback mount is active my player gets the metadata from this mount and works perfect. When the 'main' mount gets active, icecast switches perfect, and in my...I have icecast 2.4.4 with win2016 server. I'm using a fallback-mount. When the fallback mount is active my player gets the metadata from this mount and works perfect. When the 'main' mount gets active, icecast switches perfect, and in my status-json my 'main' mount is first presented so my player pickes te metadata correct. When the 'main' mount is lost and icecast switches to the fallback mount things go wrong. The music switches but in status-json the metadata from the 'main' mount is not dropped/removed so my player is looking to empty strings and is not presenting artist and song information. The 'main' mount is also not dropped in the icecast server status (but empty, containing no data). When i at this point also disconnect the fallback, both are removed from status-json. Is this a setting i have to change or a bug?
[Icecast_xml_settings.txt](/uploads/be6d02c1146dea8396b28c984b0178fa/Icecast_xml_settings.txt)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/2386Unable to disable SSL build in libshout-2.4.32020-10-01T18:33:57ZNight GryphonUnable to disable SSL build in libshout-2.4.3./configure --without-openssl
still do ssl tests and add
#define HAVE_OPENSSL 1
to config.h which cause tls.c and other unwanted ssl stuff to build in to library./configure --without-openssl
still do ssl tests and add
#define HAVE_OPENSSL 1
to config.h which cause tls.c and other unwanted ssl stuff to build in to libraryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2385[PATCH] StreamUrl metadata not included in stream2020-10-02T13:04:13ZJoakim Lagerqvist[PATCH] StreamUrl metadata not included in streamHello,
When setting the metadata over admin interface, the url parameter is ignored. For example, if the metadata is set with the following call:
`http://192.168.1.10:8000/admin/metadata?mount=/mystream&mode=updinfo&song=ACDC+Back+In+...Hello,
When setting the metadata over admin interface, the url parameter is ignored. For example, if the metadata is set with the following call:
`http://192.168.1.10:8000/admin/metadata?mount=/mystream&mode=updinfo&song=ACDC+Back+In+Black&url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FAC%2FDC`
I would expect to see the following in the stream:
`StreamTitle='ACDC Back In Black';StreamUrl='https://en.wikipedia.org/wiki/AC/DC';`
However, only the StreamTitle gets propagated. Looking into the code, most of the support is there, only missing the functionality to save the 'url' parameter in the admin section. Attached is a tested patch.
Cheers,
Joakim @ Radio Sweden/Sveriges Radio
[streamurl.patch](/uploads/8a037825e4a7ee0f2cacc3193b58fdeb/streamurl.patch)
Edit: realised there were some tabs instead of spaces in the patch.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2384Internalization2023-01-03T10:23:47ZMejansInternalizationHello,
could it be possible to have a language manager so we can display web pages in different languages?Hello,
could it be possible to have a language manager so we can display web pages in different languages?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2382Streaming over SSL disconnects2020-10-02T13:45:10ZcyberStreaming over SSL disconnectsHi,
ERROR:
Feb 25 13:27:39 hostname kernel: icecast[550]: segfault at 7f2b7fe74000 ip 00007f2b7faa3a56 sp 00007ffef066b1a0 error 4 in libcrypto.so.1.0.1e[7f2b7fa2d000+1ba000]
Feb 25 17:22:07 hostname kernel: icecast[21702]: segfault at ...Hi,
ERROR:
Feb 25 13:27:39 hostname kernel: icecast[550]: segfault at 7f2b7fe74000 ip 00007f2b7faa3a56 sp 00007ffef066b1a0 error 4 in libcrypto.so.1.0.1e[7f2b7fa2d000+1ba000]
Feb 25 17:22:07 hostname kernel: icecast[21702]: segfault at 7f31c0de6000 ip 00007f31c0a15a56 sp 00007fff82c831f0 error 4 in libcrypto.so.1.0.1e[7f31c099f000+1ba000]
We have a station configured with icecast with SSL and has random disconnections.
Versions:
/usr/local/bin/icecast -v
Icecast 2.4.4
OpenSSL 1.0.1e-fips 11 Feb 2013
CentOS release 6.10
Centova Cast 3.2.10.20170725.stable-519r4029
Does anyone know if there is any way to solve this?
All I have found is this link but there is no solution in this regard:
https://gitlab.xiph.org/xiph/icecast-server/issues/2283
Kind regards,https://gitlab.xiph.org/xiph/icecast-server/-/issues/2381Multimedia signing key expired for openSUSE OBS Multimedia2022-04-12T14:00:12ZTom ZetMultimedia signing key expired for openSUSE OBS MultimediaThe Multimedia signing key as written in here [wiki.xiph.org](https://wiki.xiph.org/index.php?title=Icecast_Server/Installing_latest_version_(official_Xiph_repositories)&mobileaction=toggle_view_desktop) expired 2020-01-30.The Multimedia signing key as written in here [wiki.xiph.org](https://wiki.xiph.org/index.php?title=Icecast_Server/Installing_latest_version_(official_Xiph_repositories)&mobileaction=toggle_view_desktop) expired 2020-01-30.Thomas B. RückerThomas B. Rücker