Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-07-09T11:30:46Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2332Change playlist_new default from 4 to 102018-07-09T11:30:46ZRoger HågensenChange playlist_new default from 4 to 10Change `src->history = playlist_new(4 /* DOCUMENT: default is max_tracks=4. */);`
To `src->history = playlist_new(10 /* DOCUMENT: default is max_tracks=10. */);`
Other servers like Shoutcast has 10, various players and webplayers has 10...Change `src->history = playlist_new(4 /* DOCUMENT: default is max_tracks=4. */);`
To `src->history = playlist_new(10 /* DOCUMENT: default is max_tracks=10. */);`
Other servers like Shoutcast has 10, various players and webplayers has 10.
Most service providers do minimal configuration changes so a default of 10 is beneficial as that is most likely what users want anyway.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2335`<no-mount>` (`<mount>`'s child) is noop in 2.5.x2021-04-14T10:51:43ZPhilipp Schafft`<no-mount>` (`<mount>`'s child) is noop in 2.5.xThe tag `<no-mount>` (which is a child element of `<mount>`) doesn't seem to do anything in 2.5.x. However according to source code comment it should disallow direct access to the mount.
This may interact with the ACL system.The tag `<no-mount>` (which is a child element of `<mount>`) doesn't seem to do anything in 2.5.x. However according to source code comment it should disallow direct access to the mount.
This may interact with the ACL system.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2336Icecast 2.5.x relays not working2018-07-26T10:19:39ZPhilipp SchafftIcecast 2.5.x relays not workingRelays do not work.
In master since 4a10d7e74422b7c3a31d4677e12f5aa3ce52474f.
client->request_body_length is not correctly set up leading to body read limit (client->request_body_length=0). client generally may not be in correct state.Relays do not work.
In master since 4a10d7e74422b7c3a31d4677e12f5aa3ce52474f.
client->request_body_length is not correctly set up leading to body read limit (client->request_body_length=0). client generally may not be in correct state.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2337RFE: Please add a possibility for a relay to transcode the stream2020-11-09T19:35:07Zpetr tomasekRFE: Please add a possibility for a relay to transcode the streamWith Icecast I'm missing the possibility to create transcoding relays in a simple manner. I'd suggest there could be a new configuration option which would specify a binary/script which the stream would go through.
Something like this:
...With Icecast I'm missing the possibility to create transcoding relays in a simple manner. I'd suggest there could be a new configuration option which would specify a binary/script which the stream would go through.
Something like this:
```xml
<relay>
<server>127.0.0.1</server>
<port>8001</port>
<mount>/example.ogg</mount>
<local-mount>/different.ogg</local-mount>
<on-demand>1</on-demand>
<retry-delay>30</retry-delay>
<relay-shoutcast-metadata>0</relay-shoutcast-metadata>
<transcode-bin>/usr/local/bin/transcodestreamXYZ</transcode-bin>
</relay>
```
Thanks!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2338SSL support on Ubuntu 18.042019-01-26T10:42:02ZSimon CechacekSSL support on Ubuntu 18.04Hello,
I am trying to run Icecast on my Ubuntu 18.04 with SSL enabled. When I add the official repository to the system and then use `apt-get install icecast2`, everything will work except that when I will turn the SSL on, I will `get I...Hello,
I am trying to run Icecast on my Ubuntu 18.04 with SSL enabled. When I add the official repository to the system and then use `apt-get install icecast2`, everything will work except that when I will turn the SSL on, I will `get INFO connection/get_ssl_certificate No SSL capability` message, I pre-installed OpenSSL befory icecast installation."
any Idea how to fix this?
I also tried to build by Icecast from the source with the custom path ovf openssl pramater enabled (just put there the default openssl path) and it worked, but this icecast is installed as an app and not as a service, so don't how to reload config without dropping listeners (i need to add relays withour restarting the server as it will server as a proxy).
Thanks for all your time!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2339After logrotate Icecast not using new access.log and error.log files2018-09-28T13:24:06ZDoug TinklenbergAfter logrotate Icecast not using new access.log and error.log filesThe logrotate postrotate command is this for Icecast: */bin/kill -HUP `cat /var/run/icecast/icecast.pid 2>/dev/null` 2> /dev/null || true*
The Icecast installation doesn't create the icecast folder in /var/run so there is no icecast.p...The logrotate postrotate command is this for Icecast: */bin/kill -HUP `cat /var/run/icecast/icecast.pid 2>/dev/null` 2> /dev/null || true*
The Icecast installation doesn't create the icecast folder in /var/run so there is no icecast.pid file.
So what's happening is that after a logrotate the Icecast service continues to use the access.log-date file rather then the new access.log file that is created during the logrotate. The only way to get it to use the new log files is to restart the icecast service.
Why is the logrotate command trying to kill a pid file that doesn't exist and is there another postrotate command that should be used instead.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2340authentication subsystem should allow the user to send a custom error2018-10-16T06:39:31ZPhilipp Schafftauthentication subsystem should allow the user to send a custom errorThe authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="a...The authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="anonymous" deny-all="*" reject-with="f955b6c6-aaca-4734-aacc-67d86bf83c3b" />
</authentication>
```
This would also be in-line with `AUTH_ALTER_SEND_ERROR`.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2342Security vulnerability: buffer overflow in URL authentication allows remote c...2018-11-05T08:00:08ZNick RolfeSecurity vulnerability: buffer overflow in URL authentication allows remote code executionHello,
I would like to report a security vulnerability in the Icecast server.
## The bug
`url_add_client` in `auth_url.c` contains this call inside a loop:
```
post_offset += snprintf(post + post_offset,
sizeo...Hello,
I would like to report a security vulnerability in the Icecast server.
## The bug
`url_add_client` in `auth_url.c` contains this call inside a loop:
```
post_offset += snprintf(post + post_offset,
sizeof(post) - post_offset,
"&%s%s=%s",
url->prefix_headers ? url->prefix_headers : "",
cur_header, header_valesc);
```
If the string to be written is longer than `sizeof(post) - post_offset`, `snprintf` will truncate the string, but will return *the number of bytes it would have written if the buffer were large enough*. This means that `post_offset` is incremented to be larger than `sizeof(post)`, and any subsequent iteration of the loop will write beyond the end of the buffer.
## Proof of concept
I configured a mount using URL authentication that forwards two headers:
```
<mount type="normal">
<mount-name>/auth_url.ogg</mount-name>
<authentication type="url">
<option name="headers" value="x-foo,x-bar"/>
...
</authentication>
</mount>
```
My Icecast server was running on localhost, port 8000, and then I ran the following Bash script:
```
foo=$(python -c "print('a' * 3950)")
bar=123456789123456789
curl -H "x-foo: $foo" -H "x-bar: $bar" http://localhost:8000/auth_url.ogg
```
The `x-foo` header was truncated, but it caused `postoffset` to be incremented beyond the size of the buffer, as described above. The subsequent handling of the `x-bar` header overwrote other stack contents, causing my Icecast server to crash:
```
*** stack smashing detected ***: <unknown> terminated
Aborted (core dumped)
```
By controlling the length of the `x-foo` header, and the contents of the `x-bar` header, it seems likely that remote code execution would be possible.
## Related bug
Our automated analysis highlighted this bug, and another similar misuse of `snprintf` in `format_prepare_headers` in `format.c`, but I did not investigate whether that one would be exploitable.
Those analysis results are visible here: https://lgtm.com/projects/g/xiph/Icecast-Server/alerts/?mode=tree&ruleFocus=1505913226124
## Disclosure
Please let me know when you have fixed the vulnerability, so that we can coordinate our disclosure with yours. For reference, here is a link to our vulnerability disclosure policy: https://lgtm.com/security
Thanks!
--Nick Rolfe, Semmle Security Research TeamThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2343Add API endpoint to sets a mark in the log files2020-10-02T13:37:21ZPhilipp SchafftAdd API endpoint to sets a mark in the log filesThis is for debugging. The endpoint would write marker into the log file. This can be helpful to find things in busy logfiles more easily.
The marker could optionally include a user provided string and username+role of the user who requ...This is for debugging. The endpoint would write marker into the log file. This can be helpful to find things in busy logfiles more easily.
The marker could optionally include a user provided string and username+role of the user who requested the mark.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2344Crash Icecast 2.4.3 on CentOS 7.52020-10-18T15:38:53ZMichelCrash Icecast 2.4.3 on CentOS 7.5Hi,
We running Icecast v2.4.3 on the Last version of CentOS Linux release 7.5.1804 (Core).
And its crash every 3 a 4 days. We see in the systemlog:
kernel: traps: icecast[5425] general protection ip:7ff3b209cc19 sp:7ffc63b5a910 error:0...Hi,
We running Icecast v2.4.3 on the Last version of CentOS Linux release 7.5.1804 (Core).
And its crash every 3 a 4 days. We see in the systemlog:
kernel: traps: icecast[5425] general protection ip:7ff3b209cc19 sp:7ffc63b5a910 error:0 in libssl.so.1.0.2k[7ff3b2070000+67000]
We run OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS 7.5 using the last updates.
We use dual stack ipv4/ipv6 and run on ssl and streaming on flac, opus and mp3.
Best regards,
Michelhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2345For close-only-review2018-11-09T07:32:50ZPhilipp SchafftFor close-only-reviewThe following tasks should be closed as they are or re-opened for review as per comment.
* [x] #2085
* [x] #2057
* [x] #2017
* [x] #2171
* [x] #1195
* [x] #1296The following tasks should be closed as they are or re-opened for review as per comment.
* [x] #2085
* [x] #2057
* [x] #2017
* [x] #2171
* [x] #1195
* [x] #1296Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2347ACL should support names2020-10-15T14:20:49ZPhilipp SchafftACL should support namesACLs should support name=""s just like Roles do for easier administration.
This will become more important when Icecast will support multiple ACLs per Role.ACLs should support name=""s just like Roles do for easier administration.
This will become more important when Icecast will support multiple ACLs per Role.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2348Auth backend for enforcing initial 4012019-04-23T13:54:32ZPhilipp SchafftAuth backend for enforcing initial 401There should be an auth backend that enforces an initial 401 reply.
This would be useful to off-load generation of those initial replies from other backends such as the URL auth backend.
This works by:
```
If (!user || !password) {
...There should be an auth backend that enforces an initial 401 reply.
This would be useful to off-load generation of those initial replies from other backends such as the URL auth backend.
This works by:
```
If (!user || !password) {
return failed;
} else {
return no match;
}
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2354Improve way of what URI is sent to YP2022-03-21T23:14:53ZPhilipp SchafftImprove way of what URI is sent to YPAt this point the URI sent to YP servers is based on the hostname and global port setting. However this does not work with TLS enabled and may not work for more complex setups with internal-/external-split (including different hostnames)...At this point the URI sent to YP servers is based on the hostname and global port setting. However this does not work with TLS enabled and may not work for more complex setups with internal-/external-split (including different hostnames).
An attribute to the `<directory>` tag should be added that takes the ID of a `<listen-socket>` on which behalf the YP submission should be made. That `<listen-socket>` may be `type="virtual"`.
See: #2171Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2355DoS vector using incorrect TLS teardown2018-12-07T13:48:18ZPhilipp SchafftDoS vector using incorrect TLS teardownWhen in a TLS SOURCE connection the socket is closed without TLS teardown Icecast will read from the socket in a tight endless loop. This locks up the corresponding thread.
Affected at least: Icecast 2.4.4, Icecast 2.5 beta 2.
May be re...When in a TLS SOURCE connection the socket is closed without TLS teardown Icecast will read from the socket in a tight endless loop. This locks up the corresponding thread.
Affected at least: Icecast 2.4.4, Icecast 2.5 beta 2.
May be related to OpenSSL version. Tested with version 1.0.1t.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2356Icecast does not handle HTTP Upgrade as to RFC2018-12-14T03:48:15ZPhilipp SchafftIcecast does not handle HTTP Upgrade as to RFCCurrently Icecast 2.5.x does not handle HTTP upgrades correctly. It does not send the final reply to the request doing the upgrade.Currently Icecast 2.5.x does not handle HTTP upgrades correctly. It does not send the final reply to the request doing the upgrade.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2358Improve Icecast's logging of developer only messages2019-04-23T13:54:32ZPhilipp SchafftImprove Icecast's logging of developer only messagesCurrently Icecast logs many details that are only of interest to developers. Those lines "spam" the error log.
There should be a way to disable those messages. This could happen using the well-known DEBUG macro OR by adding another log ...Currently Icecast logs many details that are only of interest to developers. Those lines "spam" the error log.
There should be a way to disable those messages. This could happen using the well-known DEBUG macro OR by adding another log level or log flag (as those messages may themself have different log levels as per their logic).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2359`<listen-socket>` does not support `<http-headers>`2020-10-15T20:42:13ZPhilipp Schafft`<listen-socket>` does not support `<http-headers>`Currently `<listen-socket>` does not support `<http-headers>` as a child. While I see little reason to use this there is no reason why this should not work.Currently `<listen-socket>` does not support `<http-headers>` as a child. While I see little reason to use this there is no reason why this should not work.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2360Document and define query string and POST parameters2022-03-11T12:47:10ZPhilipp SchafftDocument and define query string and POST parametersThe currently existing parameters should be documented.
Also it should be one or more or a prefix for custom parameters be defined for user specific data.
* The value(s) should be send to logging,
* the value(s) should be send to auth,
...The currently existing parameters should be documented.
Also it should be one or more or a prefix for custom parameters be defined for user specific data.
* The value(s) should be send to logging,
* the value(s) should be send to auth,
* the value(s) may be send to (fast)events.
A single value like 'token' or 'etoken' (e ➔ external) would be easy and secure to implement. However a user that needs multiple values must encode them into a single value themselfs in that case.
On the other paw a prefix could be defined (such as 'e-', e ➔ external) that is considered 'safe' (as in not used by Icecast or any future version) even if not used. This would allow future extension at some point.
currently the following parameters are universal:
* omode
* mount
The admin/-interface uses more parameters.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2362Document the unit of max-listener-duration2018-12-04T09:23:19ZnaitsirchDocument the unit of max-listener-durationIn the config documentation about the setting `max-listener-duration` it is said
> An optional value which will set the length of time a listener will stay connected to the stream.
> An auth component may override this.
See http://www....In the config documentation about the setting `max-listener-duration` it is said
> An optional value which will set the length of time a listener will stay connected to the stream.
> An auth component may override this.
See http://www.icecast.org/docs/icecast-2.4.1/config-file.html
But it is not defined if this should be given in seconds or minutes.2018-12-04https://gitlab.xiph.org/xiph/icecast-server/-/issues/2363Use of `<shoutcast-compat>` results in unexpected behaviour2020-10-11T09:01:32ZPhilipp SchafftUse of `<shoutcast-compat>` results in unexpected behaviourWhen setting `<shoutcast-mount>` within `<listen-socket>` two sockets will be created:
* A normal one with the shoutcast mount set
* A second one at (`port` + 1) with shoutcast mount set as ICY source port (`<shoutcast-compat>` set).
Ho...When setting `<shoutcast-mount>` within `<listen-socket>` two sockets will be created:
* A normal one with the shoutcast mount set
* A second one at (`port` + 1) with shoutcast mount set as ICY source port (`<shoutcast-compat>` set).
However you can set `<shoutcast-compat>` manually. In this case also two ports are opened at `port` and `port` + 1 with both being identical in configuration.
The code uses the following condition to check if the extra socket must be created:
```c
if (listener->shoutcast_mount) {
```
However I think it should be:
```c
if (listener->shoutcast_mount && !listener->shoutcast_compat) {
```
This will prevent the listen socket on `port` + 1 to be created.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2364https stream play 1 second and stop2019-05-13T11:56:47ZMichelhttps stream play 1 second and stopWe have sometimes a problems with playing in https on Icecast v 2.4.3 it starts playing and stops after a second.
But only an issue on https, the http streams are fine. When we restart the Icecast it works fine for days.
Yesterday i bul...We have sometimes a problems with playing in https on Icecast v 2.4.3 it starts playing and stops after a second.
But only an issue on https, the http streams are fine. When we restart the Icecast it works fine for days.
Yesterday i bult a new RPM for Icecast 2.4.4 on the last version of CentOS Linux release 7.6.1810 (Core) include the openssl update. (OpenSSL 1.0.2k-fips 26 Jan 2017)
I run it on the debug mode (4). Tonight i have the same problem on https on mount /live a mp3 192k stream. It play 2 seconds and stop. (when i try to use include .m3u so https.../live.m3u he go to http in the software player)
Here is the debug error log. I hope you find them useful (see /live) :
```
[2018-12-09 21:29:07] DBUG auth/add_authenticated_listener client authenticated, passed to source
[2018-12-09 21:29:07] DBUG source/source_main Client added for mountpoint (/live)
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 1
[2018-12-09 21:29:07] DBUG format/format_check_http_buffer processing pending client headers
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (15)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global connections (52301)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (16)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global connections (52302)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/flac.flac" total_bytes_read (18373627904)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/flac.flac" total_bytes_sent (82768157916)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global client_connections (50480)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/live" listeners (1)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listeners (12)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listener_connections (11687)
[2018-12-09 21:29:07] DBUG client/client_send_bytes Client connection died
[2018-12-09 21:29:07] DBUG source/source_main Client removed
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 0
[2018-12-09 21:29:07] DBUG auth/add_listener_to_source max on /live is 400 (cur 0)
[2018-12-09 21:29:07] DBUG auth/add_listener_to_source Added client to /live
[2018-12-09 21:29:07] DBUG auth/add_authenticated_listener client authenticated, passed to source
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listeners (11)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (15)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/live" listeners (0)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global client_connections (50481)
[2018-12-09 21:29:07] DBUG source/source_main Client added for mountpoint (/live)
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 1
[2018-12-09 21:29:07] DBUG format/format_check_http_buffer processing pending client headers
[2018-12-09 21:29:07] DBUG client/client_send_bytes Client connection died
[2018-12-09 21:29:07] DBUG source/source_main Client removed
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 0
```
Best regards,
Michelhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2366Icecast does list POST support for Admin interface but has it disabled for le...2019-02-02T04:30:49ZPhilipp SchafftIcecast does list POST support for Admin interface but has it disabled for legacy-global-sourceIcecast lists POST support in it's Allow. However it is by default disabled for legacy-global-source on admin/. POST should be allowed as well.Icecast lists POST support in it's Allow. However it is by default disabled for legacy-global-source on admin/. POST should be allowed as well.Philipp SchafftPhilipp Schafft2018-12-14https://gitlab.xiph.org/xiph/icecast-server/-/issues/2367Add ability to define which port Icecast should consider to be world reachable2018-12-16T23:05:43ZRemco BrinkAdd ability to define which port Icecast should consider to be world reachableI'm running Icecast in a reverse proxy setup with nginx, where nginx is taking care of SSL. Two listeners are configured, port 8000 on 127.0.0.1 for the nginx reverse proxy and port 8080 on 0.0.0.0 for clients to access streams. This set...I'm running Icecast in a reverse proxy setup with nginx, where nginx is taking care of SSL. Two listeners are configured, port 8000 on 127.0.0.1 for the nginx reverse proxy and port 8080 on 0.0.0.0 for clients to access streams. This setup allows me to serve my playlists over HTTPS, but unfortunately the generated m3u files now point to the incorrect port (8000, which only listens on 127.0.0.1).
Adding a configuration parameter that lets me specify which port I want to use for reporting to YP as well as which port Icecast should use in the generated m3u files would seem to solve this problem.
A patch was created by [Damien Garrido](https://damiengarrido.wordpress.com/2015/03/22/icecast-reachable-behind-reverse-proxy/) that solves this problem by adding an `<exposed-port></exposed-port>` configuration variable. Having this functionality included in Icecast would be a great help.
[exposed_port.icecast.patch](/uploads/803334e218a7f4e8c51aad38673ae9c7/exposed_port.icecast.patch)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2368Sending of fallback files is not rate limited2018-12-18T23:49:04ZBo AndersonSending of fallback files is not rate limitedCurrently (2.4.2 Linux), fallback files are sent at an uncapped rate which could be potentially several times faster than the playback bitrate. This causes `fallback-override` to be very ineffective. Because we are sending the files fast...Currently (2.4.2 Linux), fallback files are sent at an uncapped rate which could be potentially several times faster than the playback bitrate. This causes `fallback-override` to be very ineffective. Because we are sending the files faster than the client plays it back, its buffer gets fuller and fuller until it reaches its limit of what is potentially several minutes or hours worth of fallback file audio to play. When the client is moved back to the original mountpoint, they have to wait until they've played all of this extra fallback audio before reaching the live stream again which at that point will be very delayed compared to the the incoming stream.
Instead, the fallback files should be rate limited so that it only sends at most its playback bitrate every second. It may well be this bitrate has to be given in the form of a setting, but I feel this is an important issue to fix regardless.
---
(Migrated from https://github.com/xiph/Icecast-Server/issues/28)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2369Allow for master list to contain authentication credentials (when consumed by...2021-07-26T16:00:10ZThomas B. RückerAllow for master list to contain authentication credentials (when consumed by relay client)Extension of functionality merged as part of #1878
Add handling of auth credentials as part of URL.Extension of functionality merged as part of #1878
Add handling of auth credentials as part of URL.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2370Url events don't work when an "action" option is configured2019-02-02T04:30:49Zspr0cketeerUrl events don't work when an "action" option is configured```
<event-bindings>
<event type="url" trigger="source-connect">
...
...
<option name="action" value="mount_add" />
```
Bug is in event_url.c:event_get_url()
https://gitlab.xiph.org/xiph/icecast-server/blob/master/s...```
<event-bindings>
<event type="url" trigger="source-connect">
...
...
<option name="action" value="mount_add" />
```
Bug is in event_url.c:event_get_url()
https://gitlab.xiph.org/xiph/icecast-server/blob/master/src/event_url.c#L134
Should be `free(self->action)` not `free(self->url)`https://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/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/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/2376AAC HTML5 audio player in Chrome do not go to fallback2020-02-14T12:54:11ZMichelAAC HTML5 audio player in Chrome do not go to fallbackHi,
We have setup a test stream using Icecast 2.4.4 and use 2 mountpoint on AAC.
And use a simple HTML5 player for testing:
```
<audio controls preload="none">
<source src="https://streamdnsname/aac" type="audio/mp4" />
</audio>
```
T...Hi,
We have setup a test stream using Icecast 2.4.4 and use 2 mountpoint on AAC.
And use a simple HTML5 player for testing:
```
<audio controls preload="none">
<source src="https://streamdnsname/aac" type="audio/mp4" />
</audio>
```
This is a part of our Icecast config.
```
<mount>
<mount-name>/aac</mount-name>
<password>xxxxxxx</password>
<public>1</public>
<hidden>0</hidden>
<fallback-mount>/fk-aac</fallback-mount>
<fallback-override>1</fallback-override>
<max-listeners>1500</max-listeners>
</mount>
<mount>
<mount-name>/fk-aac</mount-name>
<password>xxxxxxx</password>
<public>1</public>
<hidden>1</hidden>
<fallback-mount>/aac.aac</fallback-mount>
<fallback-override>1</fallback-override>
<max-listeners>1500</max-listeners>
</mount>
```
We kick or stop the /aac mountpoint and the html5 player stop playing.
When we listen to a Winamp player and we kick the /aac it works fine we hear the /fk-aac.
We use on both mountpoints exact the same encoder (Sam Cast)
CODEC aacPlus 96kb/s (12,0 Kbytes/s) Samplerate 44.1 kHz Stereo
We using Chrome 74.0.3729.131 (Officiële build) (64-bits) on Win7.
When i test the same html5 player on Firefox it works fine. We use Firefox 66.0.4
For Chrome HTML player problem we see in Icecast (error log):
[2019-05-10 11:50:40] WARN format/format_get_type Unsupported or legacy stream type: "audio/aacp". Falling back to generic minimal handler for best effort.
Look like html5 player on chrome and Icecast using AAC do not work fine.
I already try some other things to use http (not https) or ip address in html5 player code. Other AAC setting for both mountpoints and use html5 player on diffrent PC and chrome.
But it not a specific problem on one PC.
I hope there is solution, many listener using the Chrome browser in portals (its my default browser)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2377Icecast leaks memory in speex module when probing for codecs2019-06-28T08:06:23ZPhilipp SchafftIcecast leaks memory in speex module when probing for codecsIcecast currently leaks memory in codec probing within the speex module. This happens if the initial packet has less then 80 bytes.Icecast currently leaks memory in codec probing within the speex module. This happens if the initial packet has less then 80 bytes.Philipp SchafftPhilipp Schafft2019-06-28https://gitlab.xiph.org/xiph/icecast-server/-/issues/2380Invalid JSON structure when title is empty2020-10-11T11:37:16ZEdwin HermannInvalid JSON structure when title is emptyBelow is a snippet of the JSON structure returned from /status-json.xsl when the song title is empty:
```
"stream_start":"Mon, 28 Oct 2019 10:49:00 +1300",
"stream_start_iso8601":"2019-10-28T10:49:00+1300",
...Below is a snippet of the JSON structure returned from /status-json.xsl when the song title is empty:
```
"stream_start":"Mon, 28 Oct 2019 10:49:00 +1300",
"stream_start_iso8601":"2019-10-28T10:49:00+1300",
"title": - ,
"dummy":null
}
```
The problem item here is "title". The resulting JSON string does not parse correctly because of the hyphen. To fix the bug, the hyphen should be enclosed in double-quotes.
The server whence this came is not mine so I am not able to determine why it is that the Icecast server is returning an unquoted hyphen. The server concerned has been that way for several days; the URL is http://219.89.83.33:8000/status-json.xslhttps://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ückerhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/2411listeners on fallback-mount don't find initially mount2021-05-08T14:13:09ZSonny Lehnlisteners on fallback-mount don't find initially mountHi there,
if listeners connect to stream1.ogg while this is down and fallback is active the
listeners are moved to wait.ogg = good, so far
If then stream2.ogg comes up, the listeners from wait.ogg are transferred to
stream2.ogg and d...Hi there,
if listeners connect to stream1.ogg while this is down and fallback is active the
listeners are moved to wait.ogg = good, so far
If then stream2.ogg comes up, the listeners from wait.ogg are transferred to
stream2.ogg and don't wait till the initially mount stream1.ogg comes up.
Why is that?
Do I have a wrong configuration:
######################################################################
please see attached picture, I can't post the content of the xml in this editor
######################################################################
![icecast-xml](/uploads/a80bdd92fc6f1b5fd20b864fea8e4fb1/icecast-xml.jpg)
Greetings from Sonnyhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2412Icescc process get down and do not restart itself sometimes2021-10-31T11:32:47ZcyberIcescc process get down and do not restart itself sometimes[strace.txt](/uploads/0b296196b41a9b62159085c24fd67e08/strace.txt)
[error.log.txt](/uploads/809f04a4b7eeef67d881d18ecf70d3e3/error.log.txt)
Hi,
This is the version we currently have:
icecast-2.4.2
I have launched a strace to the proces...[strace.txt](/uploads/0b296196b41a9b62159085c24fd67e08/strace.txt)
[error.log.txt](/uploads/809f04a4b7eeef67d881d18ecf70d3e3/error.log.txt)
Hi,
This is the version we currently have:
icecast-2.4.2
I have launched a strace to the process, I have attached the result to you.
Application process icescc for puntoblancobase is down and should be up; restarting: successful
And in error.log for the station we see this:
```
<04/26/21@17:42:56> [source] source dropped connection. disconnecting.
<04/26/21@17:43:57> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:44:27> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:44:57> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:45:27> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:45:57> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:45:59> [source] connected from 127.0.0.1
<04/26/21@17:45:59> [source] icy-name:XXXXXXXX ; icy-genre:Unspecified
<04/26/21@17:45:59> [source] icy-pub:0 ; icy-br:64 ; icy-url:http://www.xxxxxxxxxxx.es
<04/26/21@17:45:59> [source] icy-irc: ; icy-icq: ; icy-aim:
```
But in other stations icescc do not restart till we do from panel:
```
<04/26/21@15:00:36> [source] source dropped connection. disconnecting.
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:38> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:38> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:38> [dest: 95.211.135.97] server unavailable, disconnecting
```
.......
```
<04/26/21@16:22:16> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:16> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:17> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:17> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:17> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:17> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:24> [main] SIGTERM; exiting!
<04/26/21@16:22:29> [SHOUTcast] DNAS/Linux v1.9.8 (Feb 28 2007) starting up...
<04/26/21@16:22:29> [main] pid: 9099
<04/26/21@16:22:29> [main] loaded config from etc/server.conf
<04/26/21@16:22:29> [main] initializing (usermax:100 portbase:9122)...
<04/26/21@16:22:29> [main] No ban file found (etc/sc_serv.ban)
<04/26/21@16:22:29> [main] No rip file found (etc/sc_serv.rip)
<04/26/21@16:22:29> [main] opening source socket
<04/26/21@16:22:29> [main] source thread starting
<04/26/21@16:22:29> [main] opening client socket
<04/26/21@16:22:29> [main] Client Stream thread [0] starting
<04/26/21@16:22:29> [main] client main thread starting
<04/26/21@16:22:29> [source] listening for connection on port 9123
<04/26/21@16:22:33> [source] connected from 127.0.0.1
<04/26/21@16:22:33> [source] icy-name:XXXXXXXX ; icy-genre:Unspecified
<04/26/21@16:22:33> [source] icy-pub:0 ; icy-br:64 ; icy-url:http://www.xxxxxxxxx.es
<04/26/21@16:22:33> [source] icy-irc: ; icy-icq: ; icy-aim:
```
Could you tell us which could be the cause for this problem? And how to solve it?
Product name:
Centova Cast v3https://gitlab.xiph.org/xiph/icecast-server/-/issues/2414issue in status-json2021-10-26T00:50:03ZAngelo Hongensissue in status-jsonHey guys and girls, I have an issue with the json status output. We rely heavily on it for getting the stats.
When we have a service with multiple sources, the json script isn't outputting correct json. Look at the following example. Th...Hey guys and girls, I have an issue with the json status output. We rely heavily on it for getting the stats.
When we have a service with multiple sources, the json script isn't outputting correct json. Look at the following example. The json['icestats']['source'] key contains an array of 3 sources. The first one is correctly formatted, but the next to have a surplus comma at the end, and are missing the closing curly brace.
I've looked at the status-json.xsl and xml2json.xslt files, but I have no idea where this behaviour is coming from.
Any ideas? Fixes?
```
{
"icestats": {
"admin": "icemaster@localhost",
"host": "server.domain.nl",
"location": "Earth",
"server_id": "Icecast 2.4.4",
"server_start": "Wed, 19 May 2021 23:03:50 +0200",
"server_start_iso8601": "2021-05-19T23:03:50+0200",
"source": [{
"audio_info": "bitrate=192",
"bitrate": 192,
"genre": "Folk, Piraten",
"listener_peak": 124,
"listeners": 0,
"listenurl": "http://server.domain.nl:8123/autodj",
"server_description": "ZenderXXX Radio NL ",
"server_name": "ZenderXXX Radio NL ",
"server_type": "audio/mpeg",
"server_url": "https://www.ZenderXXX.nl",
"stream_start": "Wed, 19 May 2021 23:03:52 +0200",
"stream_start_iso8601": "2021-05-19T23:03:52+0200",
"title": "Walter Ostanek - Baby Doll Polka",
"dummy": null
}, {
"bitrate": 192,
"genre": "Folk, Piraten",
"listener_peak": 190,
"listeners": 0,
"listenurl": "http://server.domain.nl:8123/backup",
"server_description": "Internet Radiostation",
"server_name": "ZenderXXX Radio NL",
"server_type": "audio/mpeg",
"server_url": "https://www.ZenderXXX.nl",
"stream_start": "Sat, 19 Jun 2021 09:15:09 +0200",
"stream_start_iso8601": "2021-06-19T09:15:09+0200",
"title": "RECLAME - Adverteren Op ZenderXXX",
,
{
"bitrate": 192,
"genre": "Folk, Piraten",
"listener_peak": 136,
"listeners": 125,
"listenurl": "http://server.domain.nl:8123/stream",
"server_description": "Internetradio station",
"server_name": "ZenderXXX Radio NL",
"server_type": "audio/mpeg",
"server_url": "https://www.ZenderXXX.nl",
"stream_start": "Wed, 23 Jun 2021 09:47:27 +0200",
"stream_start_iso8601": "2021-06-23T09:47:27+0200",
"title": "STUDIO XXX",
]
}
}
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2415SSL=1 in icecast.xml and url inside .m3u and .xsph2021-10-26T00:28:24Zla-colleSSL=1 in icecast.xml and url inside .m3u and .xsphWhen we are using the SSL port declared with:
```xml
<listen-socket>
<port>8000</port>
</listen-socket>
<listen-socket>
<port>8002</port>
<ssl>1</ssl>
</listen-socket>
```
on the status page, the url...When we are using the SSL port declared with:
```xml
<listen-socket>
<port>8000</port>
</listen-socket>
<listen-socket>
<port>8002</port>
<ssl>1</ssl>
</listen-socket>
```
on the status page, the url is in https with the right port, but inside the generated .m3u file it is http:// with the right port, so it is wrong.
.m3u file example:
```
http://live.bidon.org:8002/amiens
```
It should be
```
http://live.bidon.org:8000/amiens
```
or
```
https://live.bidon.org:8002/amiens
```
.xspf file example:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<playlist xmlns="http://xspf.org/ns/0/" version="1">
<title/>
<creator/>
<trackList>
<track>
<location>http://live.bidon.org:8000/amiens</location>
<title/>
<annotation>Stream Title: test
Stream Description: test
Content Type:audio/mpeg
Current Listeners: 7
Peak Listeners: 13
Stream Genre: Various</annotation>
<info>http://www.test.org</info>
</track>
</trackList>
</playlist>
```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/2418Linking fails with "multiple definition of `global_client_list'"2021-10-26T00:32:54ZThomas SchlienLinking fails with "multiple definition of `global_client_list'"Hi,
the linking, at least on Ubuntu 21.04 and Alpine Linux (docker latest), fails with:
```
CCLD icecast
/usr/bin/ld: icecast-logging.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_li...Hi,
the linking, at least on Ubuntu 21.04 and Alpine Linux (docker latest), fails with:
```
CCLD icecast
/usr/bin/ld: icecast-logging.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-sighandler.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-connection.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-global.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-util.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-slave.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-source.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-stats.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-client.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-xslt.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-fserve.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-admin.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_ogg.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_mp3.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_midi.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_flac.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_ebml.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_kate.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_skeleton.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_opus.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-event.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-event_exec.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-auth.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-auth_htpasswd.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-auth_anonymous.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-auth_static.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-auth_enforce_auth.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-auth_url.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-yp.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_vorbis.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
collect2: error: ld returned 1 exit status
```
I used `./autogen.sh && ./configure && make -j5 install` to compile.
If I can provide any more information, please let me know.
Best regards,
Thomashttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2419"listenurl" protocol does not match protocol used to request /status-json.xsl2023-09-01T17:53:06ZHenry van Megen"listenurl" protocol does not match protocol used to request /status-json.xslIt's probably because I'm doing something completely stupid, but when I request my /status-json.xsl over https, I see 'http' in the listenurl which I can't seem to change to https instead. This is causing me all kinds of issues with unse...It's probably because I'm doing something completely stupid, but when I request my /status-json.xsl over https, I see 'http' in the listenurl which I can't seem to change to https instead. This is causing me all kinds of issues with unsecure content, CORSS stuff and other nightmares when trying to build something that can actually read this feed.
Content of: https://domain.tld:8000/status-json.xsl (actual values replaced)
```
{
"icestats": {
"admin": "email@domain.tld",
"host": "domain.tld",
"location": "location",
"server_id": "Icecast 2.4.4",
"server_start": "Mon, 09 Aug 2021 17:00:00 +0200",
"server_start_iso8601": "2021-08-09T17:00:00+0200",
"source": {
"audio_bitrate": 192000,
"audio_channels": 2,
"audio_info": "ice-bitrate=192;ice-channels=2;ice-samplerate=44100",
"audio_samplerate": 44100,
"genre": "(NULL)",
"ice-bitrate": 192,
"ice-channels": 2,
"ice-samplerate": 44100,
"listener_peak": 1,
"listeners": 1,
"listenurl": "http://domain.tld:8000/stream.ogg",
"server_description": "Description",
"server_name": "Server name",
"server_type": "audio/ogg",
"server_url": "(NULL)",
"stream_start": "Mon, 09 Aug 2021 17:01:00 +0200",
"stream_start_iso8601": "2021-08-09T17:01:00+0200",
"subtype": "Vorbis",
"dummy": null
}
}
}
```
This is my configuration file `/etc/icecast2/icecast2.xml` : (actual values replaced)
```
<icecast>
<location>location</location>
<admin>email@domain.tld</admin>
<limits>
<clients>1000</clients>
<sources>5</sources>
<queue-size>262144</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>0</burst-on-connect>
<burst-size>4096</burst-size>
</limits>
<authentication>
<source-password>password</source-password>
<relay-password>password</relay-password>
<admin-user>user</admin-user>
<admin-password>password</admin-password>
</authentication>
<hostname>mydomain.tld</hostname>
<listen-socket>
<port>8000</port>
<ssl>1</ssl>
</listen-socket>
<listen-socket>
<port>8443</port>
<ssl>1</ssl>
</listen-socket>
<http-headers>
<header name="Access-Control-Allow-Origin" value="*" />
</http-headers>
<fileserve>1</fileserve>
<paths>
<basedir>/usr/share/icecast2</basedir>
<logdir>/var/log/icecast2</logdir>
<webroot>/usr/share/icecast2/web</webroot>
<adminroot>/usr/share/icecast2/admin</adminroot>
<pidfile>/usr/share/icecast2/icecast.pid</pidfile>
<alias source="/" destination="/"/>
<ssl-certificate>/usr/share/icecast2/letsencrypt-domain-tld-icecast.pem</ssl-certificate>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<playlistlog>playlist.log</playlistlog>
<loglevel>3</loglevel>
<logsize>100000</logsize>
<logarchive>1</logarchive>
</logging>
<security>
<chroot>1</chroot>
<changeowner>
<user>icecast2</user>
<group>icecast2</group>
</changeowner>
</security>
</icecast>
```
is there a way of fixing this by changing something in the configuration, or do I have to parse the json by some external script, fix the replace the protocol itself and then serve the changed version it to my webpage? I would love to just use the content of the json and have it be correct insteadhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2420Cannot connect to icecast-radio on external sources (winamp), browser-based c...2021-10-31T13:29:41Zsuper sleepyCannot connect to icecast-radio on external sources (winamp), browser-based connection works fineI'm at my wits' end, here. I've tried listening from a different proxy, assuming that there's something wrong with my connection - anyway.
The source audio is [here](https://play.squid-radio.net/clouds). I get an access denied notifica...I'm at my wits' end, here. I've tried listening from a different proxy, assuming that there's something wrong with my connection - anyway.
The source audio is [here](https://play.squid-radio.net/clouds). I get an access denied notification - at best! - from winamp, or at worst it just rapidly tries to connect and fails without displaying any messages. Listening through the browser is a pretty strain on my memory, I want to see if this is an icecast issue, or if there's *any* ideas you might on what could be causing this. Any advice, and I do mean any advice, would be appreciated!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2421admin/includes/confirm.xsl missing -> Confirmation in admin webGUI cannot be ...2021-10-26T10:06:39ZThomas Schlienadmin/includes/confirm.xsl missing -> Confirmation in admin webGUI cannot be doneHi.
When installing with `./autogen.sh && ./configure && make -j5 install` the file admin/includes/confirm.xsl is missing and therefore, if a confirmation is needed in the admin webGUI, it cannot be done.
I fixed this by adding `includ...Hi.
When installing with `./autogen.sh && ./configure && make -j5 install` the file admin/includes/confirm.xsl is missing and therefore, if a confirmation is needed in the admin webGUI, it cannot be done.
I fixed this by adding `includes/confirm.xsl` in the `nobase_dist_admin_DATA` part of https://gitlab.xiph.org/xiph/icecast-server/-/blob/master/admin/Makefile.am.
Is there a proper way to do merge requests for this project? If I try to clone the repo in this Gitlab I only get the error that I do not have the rights to do that.Philipp SchafftPhilipp Schaffthttps://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/2424WARN connection/get_ssl_certificate Invalid cert file /home/icecast/icecast.c...2021-12-03T20:32:49ZAlex SirroshWARN connection/get_ssl_certificate Invalid cert file /home/icecast/icecast.certkeyVersion: icecast-2.4.4-2.1.x86_64 (opensuse)
Cert issuer: LetsEncrypt
File icecast.certkey is world-readable and contains concatenated fullchain.pem and a private key.
P.S.: Found a somewhat related issue on [github](https://github.com...Version: icecast-2.4.4-2.1.x86_64 (opensuse)
Cert issuer: LetsEncrypt
File icecast.certkey is world-readable and contains concatenated fullchain.pem and a private key.
P.S.: Found a somewhat related issue on [github](https://github.com/AzuraCast/AzuraCast/issues/2692)https://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/2429/admin/version.xsl is not installed2022-03-15T10:23:11ZPhilipp Schafft/admin/version.xsl is not installed`/admin/version.xsl` is not installed. (Missing in `nobase_dist_admin_DATA`.)`/admin/version.xsl` is not installed. (Missing in `nobase_dist_admin_DATA`.)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2431max listeners per one mountpoint2022-11-09T10:39:36ZCYBimax listeners per one mountpointHi, it looks like, there is limit for 20000 concurrent users per one mountpoint. Is that correct?
Thanks
Icecast 2.4.4Hi, it looks like, there is limit for 20000 concurrent users per one mountpoint. Is that correct?
Thanks
Icecast 2.4.4https://gitlab.xiph.org/xiph/icecast-server/-/issues/2434Error GPG key sign for repository (update needed on icecast.org)2022-04-12T12:00:45ZNicolas DerambureError GPG key sign for repository (update needed on icecast.org)Hello,
I've installed the icecast2 package from the opensuse repository some weeks ago doing this :
`sh -c "echo deb http://download.opensuse.org/repositories/multimedia:/xiph/Debian_10/ ./ >>/etc/apt/sources.list.d/icecast.list"`
and...Hello,
I've installed the icecast2 package from the opensuse repository some weeks ago doing this :
`sh -c "echo deb http://download.opensuse.org/repositories/multimedia:/xiph/Debian_10/ ./ >>/etc/apt/sources.list.d/icecast.list"`
and :
`wget -qO - http://icecast.org/multimedia-obs.key | sudo apt-key add -`
Then I gave more weight to the package from opensuse repository using APT pinning in order to download from opensuse and not from debian official repositories.
But today, doing apt update, I get this error :
`W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://download.opensuse.org/repositories/multimedia:/xiph/Debian_10 ./ InRelease: The following signatures were invalid: EXPKEYSIG 77EC2301F23C6AA3 multimedia OBS Project <multimedia@build.opensuse.org>
W: Failed to fetch http://download.opensuse.org/repositories/multimedia:/xiph/Debian_10/./InRelease The following signatures were invalid: EXPKEYSIG 77EC2301F23C6AA3 multimedia OBS Project <multimedia@build.opensuse.org>`
It seems the key is not signing correctly the repository now.
I've done again the command :
`wget -qO - http://icecast.org/multimedia-obs.key | sudo apt-key add -`, but the error still persists.
Any change on your side ?
Side question : do you plan to make an icecast package for Debian 11 too ? We need to keep an old server on Debian 10 only for Icecast, and we'll be enchanted to switch it off ;)
Thx !https://gitlab.xiph.org/xiph/icecast-server/-/issues/2436Icecast2 server poll infinitly2022-04-12T11:55:18ZDorianNicolasIcecast2 server poll infinitlyHello,
I tried to start a icecast2 server with the command
`icecast2 -c test.xml`
Where test.xml is an unmodified configuration file of icecast2.
Here my logs when i start the command :
```
[2022-04-12 11:34:35] WARN CONFIG/_parse...Hello,
I tried to start a icecast2 server with the command
`icecast2 -c test.xml`
Where test.xml is an unmodified configuration file of icecast2.
Here my logs when i start the command :
```
[2022-04-12 11:34:35] WARN CONFIG/_parse_root Warning, <hostname> not configured, using default value "localhost". This will cause problems, e.g. with YP directory listings.
[2022-04-12 11:34:35] WARN CONFIG/_parse_root Warning, <location> not configured, using default value "Earth".
[2022-04-12 11:34:35] WARN CONFIG/_parse_root Warning, <admin> contact not configured, using default value "icemaster@localhost".
```
Only warnings and nothing happens. I can access the icecast2 page (localhost:3000), I can access admin page with logs and it works. But no mountpoint are printed even if I modified the list. The list is empty.
So I looked why the icecast2 server doesn't load mountpoints. And i found this with strace command :
```
read(7, "\2\232\337wPP|spA`\226\275'Z\20\33m\337\2XkW\352~\255\5\30$\232\360D"..., 52) = 52
close(7) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2960, ...}) = 0
write(5, "[2022-04-12 11:33:01] INFO conn"..., 101) = 101
poll([{fd=4, events=POLLIN}], 1, 300) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 300) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 300) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 300) = 0 (Timeout)
```
And nothing more, except this infinite message like if it were waiting something. I'm working on WSL2 (Ubuntu) on Windows. I tried on Windows the same steps in the same way but I have exactly the same for both, so I don't think the problem comes from Windows or WSL. Moreover, I can access to the Icecast2 link server and I can connect to the admin panel, but it doesn't load my mountpoints.
Any help would be appreciate,
Thankshttps://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/2450a potential bug of NPD2022-09-06T00:08:21Zash1852a potential bug of NPDHi, I found a potential null pointer dereference bug in the project source code of icecast-Server, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps th...Hi, I found a potential null pointer dereference bug in the project source code of icecast-Server, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug, the red arrows represent the control flow,the file path can be seen in the blue framed section.
![image](/uploads/92074055051bc53bda3046f7bc09838d/image.png)
Although the code shown is for the latest but is still exist in current version. (https://gitlab.xiph.org/xiph/icecast-server/-/blob/master/src/format_ogg.c#L452-L454)
would you can help to check if this bug is true?thank you for your effort and patience!Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2452status-json.xsl not working (Issue #55 on github)2022-11-09T14:05:17ZKlaus Kobaldstatus-json.xsl not working (Issue #55 on github)thanks for the answer:
> status-json.xsl is deprecated. What is not deprecated is all below /admin/ (the actual API). Plus for 2.5.x there is a new /admin/publicstats endpoint that is kind-of the successor of status-json.xsl.
>
> status...thanks for the answer:
> status-json.xsl is deprecated. What is not deprecated is all below /admin/ (the actual API). Plus for 2.5.x there is a new /admin/publicstats endpoint that is kind-of the successor of status-json.xsl.
>
> status-json.xsl is an optional part (meaning it is installed by default but operators sometimes choose to remove it). While being deprecated it is still provided at this point. If your installation lacks it it's most likely because someone removed it (which might or might not have a reason). You can however you reinstall it by copying the latest versions of status-json.xsl, and xml2json.xslt (both located in /web/).
I tried
localhost:8000/admin/publicstats
produces:
400 - Unrecognised command
I am using this docker container:
moul/icecast:latest
Is there a better ready container maybe?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2460No instructions on how to add/modify ultimate HTML file to include favicon2023-02-27T17:45:25ZiconoclastheroNo instructions on how to add/modify ultimate HTML file to include faviconHow does one insert the appropriate code/files for favicons in icecast? I'm particularly interested in how to get this to show up in shortcuts as windows in Chrome.How does one insert the appropriate code/files for favicons in icecast? I'm particularly interested in how to get this to show up in shortcuts as windows in Chrome.