Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-11-13T09:03:30Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2357Alias for <role type="anonymous" deny-all="*">2018-11-13T09:03:30ZPhilipp SchafftAlias for <role type="anonymous" deny-all="*">@ePirat suggested that it would be nice to have an alias for <role type="anonymous" deny-all="*"> that only accepts matching options as well as deny-options. His main reason was to help users not to in-correctly use allow-all="*" as they...@ePirat suggested that it would be nice to have an alias for <role type="anonymous" deny-all="*"> that only accepts matching options as well as deny-options. His main reason was to help users not to in-correctly use allow-all="*" as they may not understand that it actually *is* the opposite of deny-all="*".
Maybe this should be more generalized and a kind of access profiles should be used like:
* deny-all
* listener
* source client
* admin
See also: #2353Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2353Rename auth backend "anonymous"2023-03-09T14:07:53ZPhilipp SchafftRename auth backend "anonymous"Currently the backend that matches all users is called "`anonymous`". This is technically correct by the way how it works and what it initially was meant to be used for. However that name might be misleading as to not match logged in use...Currently the backend that matches all users is called "`anonymous`". This is technically correct by the way how it works and what it initially was meant to be used for. However that name might be misleading as to not match logged in users.
I suggest that it should be renamed. The name "anonymous" would become an alias to ensure older configurations can still be read.
What new name should it have?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2352`<resource>` should allow `<authentication>`, and `<http-headers>`2018-11-05T08:07:15ZPhilipp Schafft`<resource>` should allow `<authentication>`, and `<http-headers>``<resource>`s should allow to set resource specific `<authentication>`, and `<http-headers>`.
This depends on: #2349 (for refobject and to-be-written lists)`<resource>`s should allow to set resource specific `<authentication>`, and `<http-headers>`.
This depends on: #2349 (for refobject and to-be-written lists)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2351Multiple ACLs per Role2020-10-18T16:15:17ZPhilipp SchafftMultiple ACLs per RoleIcecast should support multiple ACLs per role.
This is useful with matching in ACLs. It allows to authenticate a user and after that decide what access that user has based on matching.
Depends on: #2349 (for to-be-written lists), and #...Icecast should support multiple ACLs per role.
This is useful with matching in ACLs. It allows to authenticate a user and after that decide what access that user has based on matching.
Depends on: #2349 (for to-be-written lists), and #2350 (for matching).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2350Common matching frame work2019-01-22T06:31:38ZPhilipp SchafftCommon matching frame workCurrently the following parts of Icecast do client and client-status matching:
* `<resource>`
* `<role>` (auth)
* `<header>` (child of `<http-headers>`)
* `<event>` (child of `<event-bindings>`)
We also expect the following new users so...Currently the following parts of Icecast do client and client-status matching:
* `<resource>`
* `<role>` (auth)
* `<header>` (child of `<http-headers>`)
* `<event>` (child of `<event-bindings>`)
We also expect the following new users soon:
* `<acl>` (child of `<auth>`)
A common framework should be written to allow implementing matching.
This depends on #2349 (for refobject).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2349Icecast should use libigloo2022-03-16T01:46:29ZPhilipp SchafftIcecast should use libigloocommon/ is currently made into libigloo. Icecast should use libigloo. This ticket is about adding libigloo and using it as replacement to common/common/ is currently made into libigloo. Icecast should use libigloo. This ticket is about adding libigloo and using it as replacement to common/Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2346Icecast does not support absolute-form, and authority-form requests2018-11-06T08:33:24ZPhilipp SchafftIcecast does not support absolute-form, and authority-form requestsIcecast currently does not support absolute-form, and authority-form requests as per Section 5.3.2/5.3.3 of RFC7230. This is a "MUST" requirement as per RFC.Icecast currently does not support absolute-form, and authority-form requests as per Section 5.3.2/5.3.3 of RFC7230. This is a "MUST" requirement as per RFC.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2341Improvements to auth_result and it's usage (more and better results)2018-10-27T17:00:55ZPhilipp SchafftImprovements to auth_result and it's usage (more and better results)The enum auth_result currently implements:
* "undefined": The code comments this as "XXX: ???",
* "ok": client passed the auth backend successfully,
* "failed": client did not pass (because of invalid credentials or because of backend ma...The enum auth_result currently implements:
* "undefined": The code comments this as "XXX: ???",
* "ok": client passed the auth backend successfully,
* "failed": client did not pass (because of invalid credentials or because of backend malfunction),
* "released": used internally for on-disconnect handlers,
* "forbidden": unused,
* "no match": client is unknown to this backend,
* "user added", "user exists", "user deleted": used by management functions.
I suggest to change this the following way:
* Make "forbidden" settable by auth backends for permanent no-passes. This would terminate any auth retry. It could be useful for when the client *IS* identified (credentials match) but the backend forbids access (user has been banned, access has been terminated, ...).
* Add "backend failed" that indicates a problem with the backend, not the credentials. Such failures would include non-responsive backend servers (e.g. with URL auth) or misconfiguration (e.g. invalid file for htpasswd auth).
* Add a "user modified" for management functions as the current set does not allow updating users (only delete-then-add-again patterns).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2334Icecast 2.5 Beta binaries for Windows (Request)2022-03-21T09:31:42ZRoger HågensenIcecast 2.5 Beta binaries for Windows (Request)The last binary for Windows was beta1 in 2015. Sure I could setup a build environment, but I doubt most Windows users of Icecast build their own Icecast server (myself included).
A windows binary was also desired by Rick Keniuk on the m...The last binary for Windows was beta1 in 2015. Sure I could setup a build environment, but I doubt most Windows users of Icecast build their own Icecast server (myself included).
A windows binary was also desired by Rick Keniuk on the mailing list.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2333Make playlist generation consistent2020-10-11T16:28:01ZMarvin ScholzMake playlist generation consistentCurrently all playlist formats are generated using XSLT, but m3u is generated in C code. This should be done consistent, either all as XSLT or all in C code.
Opinions which way will be better welcome!Currently all playlist formats are generated using XSLT, but m3u is generated in C code. This should be done consistent, either all as XSLT or all in C code.
Opinions which way will be better welcome!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2330Segmentation Fault in auth.c2018-04-18T00:14:17ZMarvin ScholzSegmentation Fault in auth.cReported by hopejr on Github:
There is a seg fault on unlocking the thread on line 189 of auth.c in the function auth_release() under certain circumstances:
1. Configure a mount point with a fallback that is a relay from another server...Reported by hopejr on Github:
There is a seg fault on unlocking the thread on line 189 of auth.c in the function auth_release() under certain circumstances:
1. Configure a mount point with a fallback that is a relay from another server that is actually running (the stream must have parameter hidden=0 and fallback-override=1)
2. Start Icecast
3. Stream to Icecast, and then stop the stream after an arbitrary amount of time
4. Load the status page in the browser
At that point, there will be a seg fault as described above. It does not happen when the mount point is hidden for some reason.
Test system is running Debian 9.3. Icecast version 2.4.99.2https://gitlab.xiph.org/xiph/icecast-server/-/issues/2322gzip http compression for server pages.2019-01-09T11:59:13ZRoger Hågensengzip http compression for server pages.With Icecast 2.4.x there is no gzip compression used for served pages.
While most served pages are not that large, gzip may be the difference between a page being served in one TCP packet vs multiple.
And then there are monstrosity lik...With Icecast 2.4.x there is no gzip compression used for served pages.
While most served pages are not that large, gzip may be the difference between a page being served in one TCP packet vs multiple.
And then there are monstrosity like this http://relay.sonixcast.com/ that would clearly benefit from gzip.
gzip could even be applied to xml stats pages as PHP and other serverside scripting languages also support gzip.
While technical it may be possible to apply gzip to the actual stream I would not advise that, the benefit would be minimal in most cases and the compatibility issues with older players could be high (they may support gzip pages but not gzip audiostreams for example).
gzip should probably be enabled by default so that the "optimal" settings are enabled "out of the box".
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2311Parametrize TLS/SSL Protocol in Icecast config file2021-09-28T12:50:45ZGitlab BotParametrize TLS/SSL Protocol in Icecast config fileWe currently have the option of enabling SSL, defining ciphers and certificate files. Would you please add the option to define the protocol.
Example could be:
```
<SSL_Protocol>SSL_OP_NO_TLSv1|SSL_OP_NO_TLSv1_1|SSL_OP_NO_SSLv2|SSL_OP_...We currently have the option of enabling SSL, defining ciphers and certificate files. Would you please add the option to define the protocol.
Example could be:
```
<SSL_Protocol>SSL_OP_NO_TLSv1|SSL_OP_NO_TLSv1_1|SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3</SSL_Protocol>
```
The current ability to define ciphers is great but some ciphers are backwards compatible. From a security standpoint, it would be great to be able to control the protocols available.
Is there a workaround for me without needing to recompile as I've installed from Xiph repository.
Thank you so much for your time!Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2302Password extends into headers with BUTT shoutcast compatible source2020-02-14T13:26:12ZGary TunstallPassword extends into headers with BUTT shoutcast compatible sourceHi, I've found a bug in 2.4.3 (which if I understand correctly is the same as 2.4.2 for Linux).
Its a fairly minor one and is in part caused by the Source.
If you use BUTT (https://sourceforge.net/projects/butt/) to broadcast and setup a...Hi, I've found a bug in 2.4.3 (which if I understand correctly is the same as 2.4.2 for Linux).
Its a fairly minor one and is in part caused by the Source.
If you use BUTT (https://sourceforge.net/projects/butt/) to broadcast and setup an Icecast connection it works find. However if you set it up as a shoutcast connection and send to a shoutcast compatible port on icecast it fails.
Now the obvious question is why we'd use the "old" way of doing things. The answer is we are moving from shoutcast to icecast and a lot of our broadcasters still have the shoutcast settings and I'll like it to "just work" for them.
The problem is BUTT mixes its line endings, after the password there is just a /n but in the header lines it uses /r/n
In _handle_shoutcast_compatible in connection.c there is some code
```
/* Get rid of trailing \r\n or \n after password */
ptr = strstr (client->refbuf->data, "\r\r\n");
if (ptr)
headers = ptr+3;
else
{
ptr = strstr (client->refbuf->data, "\r\n");
if (ptr)
headers = ptr+2;
else
{
ptr = strstr (client->refbuf->data, "\n");
if (ptr)
headers = ptr+1;
}
}
```
Which unfortunately matches on the \r\n on the header, and misses the \n on the end of the password. So it uses the password a \n and the first line of the headers as the password, which fails and it rejects the connection.
For my purposes I've fix it by changing the code to:
```
/* Get rid of trailing \r\n or \n after password */
ptr = strstr (client->refbuf->data, "\n");
if (ptr)
{
headers = ptr+1;
while ( ( ptr > client->refbuf->data ) && ( ptr[-1]=='\r' ) )
{
ptr--;
}
}
```
So it finds the first \n and backtracks to remove any \r's
Obviously this is an edge case, in general people using BUTT will use icecast native connections, and most source client don't use mixed line endings. But I think my fixed version is probably more efficient on average anyway, so I think it should be safe to add.
I was going to try and submit a patch, but it looks like the code has moved on since the last version released, though even that didn't seem to use the latest changes at the time. So I'm not sure what is happening in that area. I'll leave this here and if its of any use then please include it. If you can shed more light on the evolution of the file and its worth it I can clone the latest version and test and if necessary make a patch for it.
Regards
GaryThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2270If relay with on-demand's source goes down, on_demand is no longer reported i...2020-10-11T11:40:22ZdonicsIf relay with on-demand's source goes down, on_demand is no longer reported in status-json.xsl when source returns.If you set up a relay with on-demand=1 in the relay settings, status-json.xsl will report the setting as on_demand=1. This is great, and helps with calculating total viewers on a source.
One thing I have found, though, is that if the so...If you set up a relay with on-demand=1 in the relay settings, status-json.xsl will report the setting as on_demand=1. This is great, and helps with calculating total viewers on a source.
One thing I have found, though, is that if the source goes down, the relay will stop reporting on_demand status-json.xsl. This continues even when the source comes back up. The only way to get on_demand reporting back is to restart the service.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2263Add mime.types paths for other distros2020-10-11T14:45:20ZMarvin ScholzAdd mime.types paths for other distrosWe should add some more mime.types paths, seems the current one we have does not work on FreeBSD
and OS X uses a different one.
See [this](https://groups.google.com/forum/#!topic/golang-codereviews/fIw6mRzai4U) for some more paths that ...We should add some more mime.types paths, seems the current one we have does not work on FreeBSD
and OS X uses a different one.
See [this](https://groups.google.com/forum/#!topic/golang-codereviews/fIw6mRzai4U) for some more paths that seems to be usual.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2259[PATCH] Master-Slave Aggregating Relay (multiple master setup)2017-10-05T10:40:40ZMarvin Scholz[PATCH] Master-Slave Aggregating Relay (multiple master setup)We got a pull-request on Github by [greenbender](https://github.com/greenbender):
> This pull request adds support for multiple Master-Slave relays. Something I am calling a Master-Slave Aggregating Relay.
>
> A couple of people have a...We got a pull-request on Github by [greenbender](https://github.com/greenbender):
> This pull request adds support for multiple Master-Slave relays. Something I am calling a Master-Slave Aggregating Relay.
>
> A couple of people have asked for this feature in the past and were referred to the Single-Broadcast Relay, which is OK provided you know the specific mountpoints that you want to relay ahead of time.
>
> If you are in a position where you want to relay mountpoints for more than one the master server, and one or more of the master servers adds and removes mountpoints dynamically or if you are unable to know what mountpoints are available ahead of time then this gives you the ability to aggregate all mountpoints for any numbers of master servers.
>
> Namespacing is also supported to prevent name clashes for mountpoints being relayed from different servers.
The patch can be found here:
```
https://github.com/xiph/Icecast-Server/pull/5.patch
```
For more information, see the [original Github Pull-Request](https://github.com/xiph/Icecast-Server/pull/5)!Icecast 2.5.2Thomas B. RückerThomas B. Rückerhttps://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/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/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 Schafft