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/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/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/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/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/2134Please add SSL support for Master -> Slave relay connections2021-11-10T08:58:41ZJordan EricksonPlease add SSL support for Master -> Slave relay connectionsIn considering a secure end-to-end Icecast communication chain, it would be wonderful to have the ability for SSL enabled master -> slave relay connections.In considering a secure end-to-end Icecast communication chain, it would be wonderful to have the ability for SSL enabled master -> slave relay connections.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2107Provide a way for YP Dirs to check streams2020-10-15T11:58:06ZMarvin ScholzProvide a way for YP Dirs to check streams>directory server GUID checks
>
>directory server does GET /GUID-asldjfasldfjalsdkfjasldkfj HTTP/1.0
>and either gets a 404 if it's wrong, or a 200 if it's correct.
As suggested already in early drafts of the YP Protocol, there should b...>directory server GUID checks
>
>directory server does GET /GUID-asldjfasldfjalsdkfjasldkfj HTTP/1.0
>and either gets a 404 if it's wrong, or a 200 if it's correct.
As suggested already in early drafts of the YP Protocol, there should be a proper way to check if a stream is still reachable and running (and even maybe fetch updated metadata while at it).
This could be solved by implementing HTTP 1.1 HEAD and setting some headers, or as the TODO suggest, making a dedicated endpoint for it.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1941fallback support in webm2019-06-26T17:23:34Zocxfallback support in webmDear Community,
We noticed that the fallback stream for webm is not working fine, we included a file named fallback.webm in /usr/local/share/icecast/web
if we try to access the stream when no source is connected we get the following err...Dear Community,
We noticed that the fallback stream for webm is not working fine, we included a file named fallback.webm in /usr/local/share/icecast/web
if we try to access the stream when no source is connected we get the following error:
[2013-03-28 00:14:45] INFO source/source_main listener count on /fallback.webm now 1
[2013-03-28 00:14:45] EROR format/format_check_http_buffer internal problem, dropping client
[2013-03-28 00:14:45] INFO source/source_main listener count on /fallback.webm now 0
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1606default station description for shoutcast source2018-11-10T15:54:39Zmoodefault station description for shoutcast sourcefor shoutcast source, description is not submited because there's no such thing in shoutcast world.
it would be nice if icecast server can "default" not "force" station description for shoutcast source (or even other source that has empt...for shoutcast source, description is not submited because there's no such thing in shoutcast world.
it would be nice if icecast server can "default" not "force" station description for shoutcast source (or even other source that has empty station description)
the same may applies to station name, which is not needed most of the caseMarvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/920limit of bitrate for each mountpoint2023-01-03T19:11:52ZGitlab Botlimit of bitrate for each mountpointI would like to host an icecast server on my PC and my friends could broadcast with it. But I want to limit the bitrate. The DJ cannot broadcast at more than 128 kbps. How to limit the bitrate for every mountpoint ? or for all mountpoints ?I would like to host an icecast server on my PC and my friends could broadcast with it. But I want to limit the bitrate. The DJ cannot broadcast at more than 128 kbps. How to limit the bitrate for every mountpoint ? or for all mountpoints ?Philipp SchafftPhilipp Schafft