Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2021-10-31T22:11:44Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2422Programmatically set the fallback-override value2021-10-31T22:11:44Zisaac-codeProgrammatically set the fallback-override valueAs advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fall...As advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fallback, but immediately the mountpoint is back, I cannot programmatically switch back to the mountpoint
Switching back to the former mountpoint is only possible when the fallback-override value is set to 1, but I cannot achieve that because there is no way to programmatically achieve that, which is weird.
P.S. I want users to create mountpoints via an exposed endpoint, so I don't create it manually inside the icecase.xml filehttps://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/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/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