Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2023-06-07T08:36:00Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2476Support for linking well known IDs from metadata2023-06-07T08:36:00ZPhilipp SchafftSupport for linking well known IDs from metadataIt would be nice if Icecast could auto link data when there is a well known ID for it. This is the case with e.g. MusicBrainz.
There should be a boolean setting that can be used to turn this off (e.g. for legal reasons).
This may also ...It would be nice if Icecast could auto link data when there is a well known ID for it. This is the case with e.g. MusicBrainz.
There should be a boolean setting that can be used to turn this off (e.g. for legal reasons).
This may also be implemented on top of #2475 by adding defaults to it.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2475Content resolver support2023-06-07T09:04:02ZPhilipp SchafftContent resolver supportAs there is not yet been a content resolver set up for Icecast and/or the foundation I would like to suggest the following:
Icecast should be extended with a set of settings used to generate URLs for content resolver requests. Initially...As there is not yet been a content resolver set up for Icecast and/or the foundation I would like to suggest the following:
Icecast should be extended with a set of settings used to generate URLs for content resolver requests. Initially there should be support for generating links to documentation. Other types (such as fetches) might later be added.
The I suggest to allow a template style URLs as values with `%`-prefixed parameters to be substituted.
As a reference "`ise-uri-template`" (`82ebe8fa-8b04-415a-ba90-16267465ef71`) defines:
> A URI template for accessing a resolver. This should not be used directly but my using one of the relations derived from it. Such templates are meant to be attached to contexts to allow easy access to resolvers without the need to set direct URIs on every tag.
>
> Templates are used as is with the following variables replaced by correctly URI encoded values. If a given value is not available this template is not available.
>
> * "%I": Any ISE of the tag
> * "%U": The UUID of the tag
> * "%O": The OID of the tag
> * "%R": The URI of the tag
>
> The use of those values is mostly safe as "%" is a special character in URIs that can only be followed by digits, or the letters "a" to "f". However some applications generate invalidly encoded Unicode URIs containing values in the form of "%uNNNN". Those are invalid by themself and therefore not valid in such templates.
I would like to extend that by providing three more substitutions:
* A generic one for the identifier (in any type/encoding)
* The name of the type/encoding used
* The name of the type/encoding used but the value `ise` for any ISE type (UUID, OID, URI).
If such parameters are added a note should be added to the code to make clear that they do not follow the `ise-uri-template` rules. However they may be added or at least reserved for `ise-uri-template` to avoid future syntax collisions.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/2138VCLT support in current icecast is useless2018-03-06T12:49:38ZPhilipp SchafftVCLT support in current icecast is uselessIn current state VCLT support is in codebase but not exposed anywhere beside the admin interface. As of current state it is of no use as it is not exposed to the listeners in any way.
I request to
1. enable support by making it as visib...In current state VCLT support is in codebase but not exposed anywhere beside the admin interface. As of current state it is of no use as it is not exposed to the listeners in any way.
I request to
1. enable support by making it as visible as the other formats OR
1. disable it by removing the code to avoid any maintenance need in future releases.
dm8tbr acknowledged to take a decision on this before final release of 2.5.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2127Icecast needs a web-UI for configuration2018-03-06T12:49:38ZThomas B. RückerIcecast needs a web-UI for configurationThere are various existing projects, open and proprietary, but none really make full use of the potential, while being usable.
The Icecast project should have its own reference configuration UI. Either from scratch or by adopting an exis...There are various existing projects, open and proprietary, but none really make full use of the potential, while being usable.
The Icecast project should have its own reference configuration UI. Either from scratch or by adopting an existing open source project.
There are two possible approaches:
* Internal (somehow as part of /admin)
* External (running on a proper web server)
The former would make it self-contained, while the latter would enable us to leverage an existing framework.
Both approaches need to be explored before a decision is made.
PS: Being fairly self-contained this would be potentially a very good GSoC or similar project. I am also sufficiently familiar with the config file and live config mechanics to mentor such a task.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1892Allow transient reconfiguration of all mount point parameters2018-03-06T12:49:39ZThomas B. RückerAllow transient reconfiguration of all mount point parametersgive the source user more freedom in controlling mount point options through admin requests.
How do we split control of <mount> options?
We could have XML tag attributes to control outside access: <stream-name allow-override="no">fooba...give the source user more freedom in controlling mount point options through admin requests.
How do we split control of <mount> options?
We could have XML tag attributes to control outside access: <stream-name allow-override="no">foobar</stream-name>
where override could be:
* yes - allow setting this value externally
* no - only the xml config file value may set this
* 'unset' - a default value is used if the attribute is not set. The default should be documented though!
Also, we should check the life-cycle for this. Do the settings get reset to the XML defined settings and defaults upon disconnection of the source client or do they persist until either the config is reloaded or the server restarted? I'd tend towards the latter and give an option to 'reset' from source side both during connect and at arbitrary points in time.Icecast 2.6Thomas B. RückerThomas B. Rücker