Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2020-10-02T13:04:13Zhttps://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ückerhttps://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/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/2374Double quote in user agent causes malfomed log file2019-07-28T07:50:31ZNeil PalmerDouble quote in user agent causes malfomed log fileSome devices include a double quote character in their user agent.
The icecast log file quotes the user agent field, but does not escape any quotes inside of this, causing an invalid format.
Example:
> "Mozilla/5.0 (Linux; Android 5....Some devices include a double quote character in their user agent.
The icecast log file quotes the user agent field, but does not escape any quotes inside of this, causing an invalid format.
Example:
> "Mozilla/5.0 (Linux; Android 5.1; Alba 8" Build/LMY47I) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.91 Safari/537.36"https://gitlab.xiph.org/xiph/icecast-server/-/issues/2373Incorrect status code2020-10-15T16:20:55ZPhilipp SchafftIncorrect status codeIn case of 'mountpoint will not accept URL updates' and other admin errors Icecast might send incorrect HTTP status headers.
This happens at least in branch ph3-mdoule-client-tests.In case of 'mountpoint will not accept URL updates' and other admin errors Icecast might send incorrect HTTP status headers.
This happens at least in branch ph3-mdoule-client-tests.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2372Icecast 'locks up' on SIGHUP if there are duplicate listener-sockets in the c...2020-10-10T10:13:32ZThomas B. RückerIcecast 'locks up' on SIGHUP if there are duplicate listener-sockets in the configAs reported by 'szett' on IRC.
Excerp of the offending config file:
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</li...As reported by 'szett' on IRC.
Excerp of the offending config file:
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</listen-socket>
<!-- SOCKET FOR SOURCES -->
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</listen-socket>Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/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/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/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/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/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/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/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/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/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/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/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 Schafft