Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2017-10-05T10:40:40Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2256Icecast 2.4.2 hangs after several hours running2017-10-05T10:40:40ZDaniel LafraiaIcecast 2.4.2 hangs after several hours runningI have a couple of Icecast servers at Digital Ocean used as a relay to our main Icecast server at AWS. For some reason the edge server (the one receiving connections from end users) hangs completely.
I had to setup Supervisord to do an ...I have a couple of Icecast servers at Digital Ocean used as a relay to our main Icecast server at AWS. For some reason the edge server (the one receiving connections from end users) hangs completely.
I had to setup Supervisord to do an HTTP request to status.xsl to determine if it's up, so it can be restarted when it happens (status.xsl request times out). Actually this happens both servers, same behavior hanging every 1 or 2 days or so.
This is not a busy streaming server (about 400 listeners peak each). When it hangs sometimes it's not on peak hours, I've seen it happening early morning.
Error_log stops longing when it happens, so there's not much information there (using loglevel 3).
This icecast server is running in a docker container, just like the main server. I'm starting this docker image with ulimit 1024:1024 for nofile.
How can I provide you with more info so we can see if this is a bug?Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2248File extension check ignores trailing characters2017-10-05T10:40:40ZMarvin ScholzFile extension check ignores trailing charactersThe `util_check_valid_extension` function will ignore any characters after a matched file extension, so that `xsl`, `xslt` and `xslfoooo` will all return `XSLT_CONTENT`, even though the last one really should not.
Additionally there is ...The `util_check_valid_extension` function will ignore any characters after a matched file extension, so that `xsl`, `xslt` and `xslfoooo` will all return `XSLT_CONTENT`, even though the last one really should not.
Additionally there is a check for `htm` and after that another one for `html`, but the first check will always match even in the case of html, so that code is actually useless and never execute.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2247XSLs are returned in plaintext if trailing dot is appended to the URL (Window...2018-04-16T22:12:13ZMarvin ScholzXSLs are returned in plaintext if trailing dot is appended to the URL (Windows only)If requesting an xsl file, anyone can get a unprocessed version of that file, possibly exposing internal information to the user, by appending a dot to the requested filename:
```
http://localhost:8000/status.xsl.
```
Only Windows is...If requesting an xsl file, anyone can get a unprocessed version of that file, possibly exposing internal information to the user, by appending a dot to the requested filename:
```
http://localhost:8000/status.xsl.
```
Only Windows is affected. This is due to the way the Windows API handles filenames, as it strips the trailing dot and will assume status.xsl instead of the version with the trailing dot.
*Unix and Linux builds were never affected.*
(See CVE-2005-0837 and #635)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2246Check Icecast2 for support to whatever result of #22332018-06-16T21:36:36ZPhilipp SchafftCheck Icecast2 for support to whatever result of #2233Icecast2 should support whatever the outcome is to icecast-libshout#2233. This ticket should be updated once icecast-libshout#2233 is closed to list what needs to be done on the server side.Icecast2 should support whatever the outcome is to icecast-libshout#2233. This ticket should be updated once icecast-libshout#2233 is closed to list what needs to be done on the server side.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2245Move TLS options out of <paths>2018-06-15T20:50:30ZPhilipp SchafftMove TLS options out of <paths>The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2237[PATCH] Detect Keyframes in WebM streams2018-03-06T12:49:37ZJoseph Wallace[PATCH] Detect Keyframes in WebM streamsThe existing WebM plugin will mark the start of any cluster as a sync point. This causes problems for web browsers, which tend to strictly demand that video streams are started on a keyframe.
The WebM specs call for a keyframe being the...The existing WebM plugin will mark the start of any cluster as a sync point. This causes problems for web browsers, which tend to strictly demand that video streams are started on a keyframe.
The WebM specs call for a keyframe being the first video frame in a cluster if the cluster contains a keyframe, but they do not require clusters to contain any keyframes at all.
This patchset:
1. implements some EBML parsing functions, to identify clusters accurately instead of assuming any occurrence of the cluster magic number is a cluster header.
2. detects if a WebM stream contains a track of type video.
3. examines the SimpleBlocks of each cluster to determine if the first video track block is marked as a keyframe.
If the first video block is a keyframe, the cluster is marked as a sync point. If the first video block is NOT a keyframe, the cluster is not marked as a sync point.
If a determination cannot be made in the first 4K of the cluster, it's optimistically marked as a sync point, since it's most likely an audio-only stream.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2231process hangs after HUP signal2023-05-08T09:49:13Zhk_netprocess hangs after HUP signalwe got icecast 2.4.2 running fine, but some times after several HUP signals for logrotation the process hangs, no more listening on its tcp-socket nor logging anything.
stopping and restarting helps to get the stream working again, but ...we got icecast 2.4.2 running fine, but some times after several HUP signals for logrotation the process hangs, no more listening on its tcp-socket nor logging anything.
stopping and restarting helps to get the stream working again, but we do have no clue how to find the issue causing this behavior.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2226Adding <mount-title> for mountpoints2018-11-10T15:54:39ZvtangerAdding <mount-title> for mountpointsAs there are a number of semi-defective clients which do not transmit a description/title as well as people out there who cannot reliably enter the display title into their client configuration, such an override-option in the configurat...As there are a number of semi-defective clients which do not transmit a description/title as well as people out there who cannot reliably enter the display title into their client configuration, such an override-option in the configuration would come handy. Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2223Icecast does not support HEAD requests2018-11-30T12:05:07ZOndra PelechIcecast does not support HEAD requestsalso reported on [Github](https://github.com/xiph/Icecast-Server/issues/2)
this makes transcodig in browser via javascript impossible
affects:
* [Aurora.js](https://github.com/audiocogs/aurora.js/issues/135)
* [Ampache](https://githu...also reported on [Github](https://github.com/xiph/Icecast-Server/issues/2)
this makes transcodig in browser via javascript impossible
affects:
* [Aurora.js](https://github.com/audiocogs/aurora.js/issues/135)
* [Ampache](https://github.com/ampache/ampache/issues/933)
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2222m3u link contents2018-11-18T10:50:03Zitmmediam3u link contentswhen attempting to play a stream from the links on the icecast server web interface the contents of the m3u file uses the wrong port number.
this may be related to ticket #2180
when connected to the server web interface with ssl ( http...when attempting to play a stream from the links on the icecast server web interface the contents of the m3u file uses the wrong port number.
this may be related to ticket #2180
when connected to the server web interface with ssl ( https ) on port 8001 ( audio clients connect via port 8000 without ssl ) the contents of the m3u file when clicking on the icon, contains port 8001 instead of 8000. the other links/icons ( vclt and xpsf ) seem to be correct.
audio streams are anonymous relays of streams from web sites accessed by clients ( winamp ) on a local area network. this issue happens with any/all configured relays.
M3U contents: ( wrong port )
`http://192.168.xxx.xxx:8001/mountpoint`
NOTE: This should be
`http://192.168.xxx.xxx:8000/mountpoint`
or
`http://servername:8000/mountpoint`
VCLT contents: ( ok ? )
```
STREAMURL=http://servername:8000/mountpoint
TITLE=
SERVER_NAME=Orange Cty - For more ...
DESCRIPTION=Unspecified description
SIGNALINFO=
GENRE=Railroad Radio Scanner
==
```
XPSF contents: ( ok ? )
```xml
<?xml version="1.0" encoding="UTF-8"?>
<playlist xmlns="http://xspf.org/ns/0/" version="1">
<title></title>
<creator></creator>
<trackList>
<track>
<location>http://servername:8000/mountpoint</location>
<title></title>
<annotation>Stream Title: Orange Cty - For more ...
Stream Description: Unspecified description
Content Type:audio/mpeg
Bitrate: 28
Current Listeners: 1
Peak Listeners: 1
Stream Genre: Railroad Radio Scanner</annotation>
<info>http://www.streamwebsite.url</info>
</track>
</trackList>
</playlist>
```
parts of icecast.xml:
```xml
<!-- You may have multiple <listener> elements -->
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</listen-socket>
<!-- admin port on 8001 using ssl -->
<!-- added/enabled Thu Jan 22 08:31:43 PST 2015 -->
<listen-socket>
<port>8001</port>
<ssl>1</ssl>
</listen-socket>
<relay>
<!-- http://railaudio.stream-host-name:stream-port/ -->
<server>railaudio.stream-host-name</server>
<port>stream-port</port>
<mount>/</mount>
<local-mount>/mountpoint</local-mount>
<on-demand>1</on-demand>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
</relay>
```
connecting to admin panel at:
`https://192.168.xxx.xxx:8001/`
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2205Allow icy-description override with stream-description from config2020-05-14T08:51:14ZMarvin ScholzAllow icy-description override with stream-description from configCurrently only the stream-name will override the icy-name header, we should implement the same handling for stream-description and icy-description as there are source clients that do not sent those headers.
(See [18543] and #1359)Currently only the stream-name will override the icy-name header, we should implement the same handling for stream-description and icy-description as there are source clients that do not sent those headers.
(See [18543] and #1359)Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2201network throughput limited at 70mbps2018-07-07T09:17:24Zwilson chuanetwork throughput limited at 70mbpsHi I have setup 3 icecast servers for eradioportal.com. These are running in a hyperV environment using CentOS v6.6
I have noticed that despite being on a 1gbps connection, the maximum network throughput i am getting is somewhere aroun...Hi I have setup 3 icecast servers for eradioportal.com. These are running in a hyperV environment using CentOS v6.6
I have noticed that despite being on a 1gbps connection, the maximum network throughput i am getting is somewhere around the 70mbps only.
Is this a bug? or is this a misconfiguration error?
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2200icecast stats addition (per mount cumulative listener counter)2018-07-07T09:19:54Zddndukkicecast stats addition (per mount cumulative listener counter)Currently in icecast statistics available counter like 'hit count' only globally in <icecasts/> node. I mean 'listener_connections'
It will be very good to add per-mount counter like that (accumulated counter of listener connections).
s...Currently in icecast statistics available counter like 'hit count' only globally in <icecasts/> node. I mean 'listener_connections'
It will be very good to add per-mount counter like that (accumulated counter of listener connections).
so it appears in /icecasts/source/ node with name like 'listener_connections'.
<icestats>
<listener_connections>3</listener_connections>
<source mount="/test">
<listener_connections>2</listener_connections>
...
</source>
</icecasts>
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2188Fowarding of headers to authentication system not working2019-06-26T17:17:19ZSebastianFowarding of headers to authentication system not workingHey everyone,
i tried to forward some cookies or other headers to my authentication sytem. Unfortunately this does not work. The doc says the headers would be part of a POST but they don't appear. Can anyone confirm that?
```
<...Hey everyone,
i tried to forward some cookies or other headers to my authentication sytem. Unfortunately this does not work. The doc says the headers would be part of a POST but they don't appear. Can anyone confirm that?
```
<option name="headers" value="x-pragma,x-token"/>
<option name="header_prefix" value="ClientHeader."/>
```
```
<mount>
<mount-name>/example.ogg</mount-name>
<authentication type="url">
<option name="mount_add" value="http://auth.example.org/stream_start.php"/>
<option name="mount_remove" value="http://auth.example.org/stream_end.php"/>
<option name="listener_add" value="http://auth.example.org/listener_joined.php"/>
<option name="listener_remove" value="http://auth.example.org/listener_left.php"/>
<option name="username" value="user"/>
<option name="password" value="pass"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
<option name="timelimit_header" value="icecast-auth-timelimit:"/>
<option name="headers" value="x-pragma,x-token"/>
<option name="header_prefix" value="ClientHeader."/>
<option name="stream_auth" value="http://auth.example.org/source.php"/>
</authentication>
</mount>
```
Best Regards
SebastianThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2179URL Auth with iOS not working correctly2017-10-05T10:40:40ZSebastianURL Auth with iOS not working correctlyHi guys,
when using an IOS device like iPad or iPhone the function "url_add_client" in the file "auth_url.c" seems not to forward all parameters correctly to the authentication system (in my case verify.php).
The username is missing as...Hi guys,
when using an IOS device like iPad or iPhone the function "url_add_client" in the file "auth_url.c" seems not to forward all parameters correctly to the authentication system (in my case verify.php).
The username is missing as you can see in the example below (PHP_AUTH_USER is empty).
After the initial "HTTP/1.0 401 Authentication Required" three GET requests are sent by mobile clients (Android, as well as iPhones or iPads). I checked that with Wireshark. On Android phones the username is never empty, that's why it is always working there.
On iPhones and iPads we have the result below.
The following data is captured from the requests of Icecast to the authentication system (verify.php).
Have a look at the cut off "HTTP_AUTHORIZATION" and the missing username in "PHP_AUTH_USER"
Do you have any idea what is going on there?
New request:
```
CONTENT_TYPE: application/x-www-form-urlencoded
CONTENT_LENGTH: 349
HTTP_USER_AGENT: Icecast 2.4.99.1
HTTP_HOST: www.domain.com
HTTP_AUTHORIZATION: Basic dm9sbDpob3JzdA==
HTTP_ACCEPT: */*
HTTP_CONTENT_TYPE: application/x-www-form-urlencoded
HTTP_CONTENT_LENGTH: 349
PHP_AUTH_USER: peter
PHP_AUTH_PW: pan
```
New request:
```
CONTENT_TYPE: application/x-www-form-urlencoded
CONTENT_LENGTH: 340
HTTP_USER_AGENT: Icecast 2.4.99.1
HTTP_HOST: www.domain.com
HTTP_AUTHORIZATION: Basic OmhvcnN0
HTTP_ACCEPT: */*
HTTP_CONTENT_TYPE: application/x-www-form-urlencoded
HTTP_CONTENT_LENGTH: 340
PHP_AUTH_USER:
PHP_AUTH_PW: pan
```
New request:
```
CONTENT_TYPE: application/x-www-form-urlencoded
CONTENT_LENGTH: 340
HTTP_USER_AGENT: Icecast 2.4.99.1
HTTP_HOST: www.domain.com
HTTP_AUTHORIZATION: Basic OmhvcnN0
HTTP_ACCEPT: */*
HTTP_CONTENT_TYPE: application/x-www-form-urlencoded
HTTP_CONTENT_LENGTH: 340
PHP_AUTH_USER:
PHP_AUTH_PW: pan
```
Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2175Url auth with HTTPS on Win not working2022-03-21T09:31:08ZSebastianUrl auth with HTTPS on Win not workingHi guys,
i tried url auth yesterday with an https link on windows.
I get this error here:
```
[2015-03-12 16:55:20] WARN auth_url/auth_url.c auth to server https://www.domain.com/auth.php failed with Problem with the SSL CA cert (pat...Hi guys,
i tried url auth yesterday with an https link on windows.
I get this error here:
```
[2015-03-12 16:55:20] WARN auth_url/auth_url.c auth to server https://www.domain.com/auth.php failed with Problem with the SSL CA cert (path? access rights?)
```
With this configuration:
```
<mount type="normal">
<mount-name>/radio</mount-name>
<max-listeners>10</max-listeners>
<username>...</username>
<password>...</password>
<authentication type="url">
<option name="listener_add" value="http://www.domain.com/auth.php"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
</authentication>
</mount>
```
I know that you have tried to make it run for windows. I just wanted to keep it tracked here.
Comments/ideas from tbr to that:
"it is working fine on linux. It might work on windows, but nobody figured out how to feed the CA path or file to the curl/nss combination."
"if someone figures out how OR if I switch to Fedora as the build distro, then it /might/ you're free to build on fedora, then it would link against an openssl curl and that might work, or not."
Thanks.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2173Max duration support for stream dumpfiles2022-03-22T17:48:23ZThomas B. RückerMax duration support for stream dumpfilesWe've received a request on this topic:
```
My suggestion is that the dump-file tag have an interval option or tag so
that it creates a new dump file based on this interval, and named based
on some sort of dump-file-name tag which wou...We've received a request on this topic:
```
My suggestion is that the dump-file tag have an interval option or tag so
that it creates a new dump file based on this interval, and named based
on some sort of dump-file-name tag which would use BASH naming variables
to name it.
```
http://lists.xiph.org/pipermail/icecast/2015-March/013209.html
Basically boils down to setting a duration and after that reopening the dump file. We already support strftime patterns in the file name.
I have received a patch for this against 2.3.2 and we'll evaluate if it can be reused or at least used as inspiration.
Optional related feature: dump files triggered / turned on/off through admin request.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2170Mingw32 is unable to "ignore" a pointer to that points to an incomplete type.2018-03-06T12:49:47ZSebastianMingw32 is unable to "ignore" a pointer to that points to an incomplete type.Hi guys,
i tried to compile with mingw32 on a fresh open suse 13.2 system. In order to get the .exe for Windows.
The result:
http://pastebin.com/dZpP3Dwh
Is it a missing configuration or is it really mingw32 that is unable to compile...Hi guys,
i tried to compile with mingw32 on a fresh open suse 13.2 system. In order to get the .exe for Windows.
The result:
http://pastebin.com/dZpP3Dwh
Is it a missing configuration or is it really mingw32 that is unable to compile it.
Considering the error messages: Is catching the error somehow possible in xslt.c?
Best Regards
SebastianThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2166Customizable .ico file via config2018-03-06T12:49:47ZSebastianCustomizable .ico file via configI want to be able to replace it with my own =) Just a wish...I want to be able to replace it with my own =) Just a wish...Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2145Adding <outro> file for mountpoints2018-03-06T12:49:38ZJordan EricksonAdding <outro> file for mountpointsHello, I thought of the idea of adding an <outro> file for mountpoints. This would operate like <intro>, but the file would be played immediately after a source disconnects and before the <intro> of any fallback mounts that listeners are...Hello, I thought of the idea of adding an <outro> file for mountpoints. This would operate like <intro>, but the file would be played immediately after a source disconnects and before the <intro> of any fallback mounts that listeners are moved to. Thank you for your consideration =)Thomas B. RückerThomas B. Rücker