Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-11-05T08:07:15Zhttps://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/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/2168Icecast should expose the YP server messages to the admin status pages per mount2018-06-16T22:44:50ZThomas B. RückerIcecast should expose the YP server messages to the admin status pages per mountThere are hundreds if not thousands of streams that fail to list properly on dir.xiph.org and it's obvious that nobody notices.
The admin interface should expose detailed information about the status of a YP listing. As per #2167 a simp...There are hundreds if not thousands of streams that fail to list properly on dir.xiph.org and it's obvious that nobody notices.
The admin interface should expose detailed information about the status of a YP listing. As per #2167 a simplified status should be also exposed to the XML used for public status.
People don't read the error.log, ever, especially in this case.
We should expose:
* If the YP server accepted the initial touch
* If the server accepted the latest touch
* What was the last status message from the YP server for a failed touch
* What was the latest status message from the YP server, including successful
* Count of YP touches since source connection
* Count of failed YP touches since source connection
Rationale is, that there might be intermittent failures so we should expose both latest message and latest failure. Also latest message, if successful could contain some information like "server outdated and insecure, please update" or otherwise from the YP administration.
Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2167Icecast should expose the YP listing status to the public status pages2018-06-16T22:44:16ZThomas B. RückerIcecast should expose the YP listing status to the public status pagesThere are hundreds if not thousands of streams that fail to list properly in dir.xiph.org and it's obvious that nobody notices.
/admin/stats should expose a per mount status field if the given mount is set public and directory listings ...There are hundreds if not thousands of streams that fail to list properly in dir.xiph.org and it's obvious that nobody notices.
/admin/stats should expose a per mount status field if the given mount is set public and directory listings are enabled for the server.
Logic could be as follows:
* *OK* - No known errors for this mount
* *WARN* - During the last n yp-touches at least one error was received
* *FAIL* - No successful listing/touch for this mount
Further information, including verbatim messages from YP should be available through the admin interface. Covered in a separate ticket.Icecast 2.5.0Thomas 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/1973Allow standard HTTP method instead of non-standard "STATS" for opening stats ...2023-01-28T20:46:15ZjA_cOpAllow standard HTTP method instead of non-standard "STATS" for opening stats streamMany HTTP libraries don't support using non-standard HTTP methods, so this can be a blocking issue.
Many HTTP libraries don't support using non-standard HTTP methods, so this can be a blocking issue.
Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://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/1860[PATCH] Send credentials when doing master-relay2018-11-10T13:05:22Zcato[PATCH] Send credentials when doing master-relayWhen using a configuration with a hidden master and some relays using master-relay it should be possible to enable password protection on streams in the master icecast. Therefore it is necessary for the relaying-icecast to send credentia...When using a configuration with a hidden master and some relays using master-relay it should be possible to enable password protection on streams in the master icecast. Therefore it is necessary for the relaying-icecast to send credentials to the master-icecast. The natural choice would be to send the `<master-username>` and `<master-password>`.Icecast 2.5.0Thomas 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/591Bandwidth stats2023-01-03T19:11:54ZGitlab BotBandwidth statsIn icecast1 it was possible to fetch the current used/maximum bandwidth on the server. It seems like these stats got lost in the icecast2 rewrite, and it would be neat to have them back.
It's not anything critical, but it's good to be ab...In icecast1 it was possible to fetch the current used/maximum bandwidth on the server. It seems like these stats got lost in the icecast2 rewrite, and it would be neat to have them back.
It's not anything critical, but it's good to be able to see how much bandwidth the server uses.Icecast 2.6Philipp SchafftPhilipp Schafft