Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2023-02-27T17:45:25Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2460No instructions on how to add/modify ultimate HTML file to include favicon2023-02-27T17:45:25ZiconoclastheroNo instructions on how to add/modify ultimate HTML file to include faviconHow does one insert the appropriate code/files for favicons in icecast? I'm particularly interested in how to get this to show up in shortcuts as windows in Chrome.How does one insert the appropriate code/files for favicons in icecast? I'm particularly interested in how to get this to show up in shortcuts as windows in Chrome.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2360Document and define query string and POST parameters2022-03-11T12:47:10ZPhilipp SchafftDocument and define query string and POST parametersThe currently existing parameters should be documented.
Also it should be one or more or a prefix for custom parameters be defined for user specific data.
* The value(s) should be send to logging,
* the value(s) should be send to auth,
...The currently existing parameters should be documented.
Also it should be one or more or a prefix for custom parameters be defined for user specific data.
* The value(s) should be send to logging,
* the value(s) should be send to auth,
* the value(s) may be send to (fast)events.
A single value like 'token' or 'etoken' (e ➔ external) would be easy and secure to implement. However a user that needs multiple values must encode them into a single value themselfs in that case.
On the other paw a prefix could be defined (such as 'e-', e ➔ external) that is considered 'safe' (as in not used by Icecast or any future version) even if not used. This would allow future extension at some point.
currently the following parameters are universal:
* omode
* mount
The admin/-interface uses more parameters.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2409The <no-mount> flag should be visible at the status page2022-02-28T11:17:41ZPhilipp SchafftThe <no-mount> flag should be visible at the status pageThe `<no-mount>` flag should be visible at the status page. At least the player and the playlist links should be removed.The `<no-mount>` flag should be visible at the status page. At least the player and the playlist links should be removed.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2261Check if bitrate is missing on admin stats page2020-10-10T11:46:49ZMarvin ScholzCheck if bitrate is missing on admin stats pageAs asked by Jack Elliott on the mailing list:
> A RFE: would it be possible for the current stream bitrates to be
> displayed on stats.xsl ?As asked by Jack Elliott on the mailing list:
> A RFE: would it be possible for the current stream bitrates to be
> displayed on stats.xsl ?Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2396Unifiy <xsl:output>-settings for web/ and admin/2020-10-09T16:38:28ZPhilipp SchafftUnifiy <xsl:output>-settings for web/ and admin/`<xsl:output>`-settings must match web/ and admin/ as they share some templates.`<xsl:output>`-settings must match web/ and admin/ as they share some templates.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/807Viewing the last X number of lines from logfile in Icecast Web Admin2020-10-02T11:46:58Zdj_transidViewing the last X number of lines from logfile in Icecast Web AdminIn the Icecast web admin is it possible to have it show say X number of lines from the errors.log just so that the admin doesnt need to have shell access to know what is going on the background, shoutcast has the same thing where it tail...In the Icecast web admin is it possible to have it show say X number of lines from the errors.log just so that the admin doesnt need to have shell access to know what is going on the background, shoutcast has the same thing where it tails the log file. just a thought.
Thanks,
~BrianIcecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1851Should Icecast use $hostname instead of the value from the GET request for re...2018-11-10T12:44:08ZThomas B. RückerShould Icecast use $hostname instead of the value from the GET request for replies?Icecast uses the hostname supplied by the client in HTTP headers for replies. Should it use the hostname set in the config instead?
Target is 2.4.0
_after some discussion on IRC:_
It is apparent that the current behaviour is well suit...Icecast uses the hostname supplied by the client in HTTP headers for replies. Should it use the hostname set in the config instead?
Target is 2.4.0
_after some discussion on IRC:_
It is apparent that the current behaviour is well suited as general purpose default. (This e.g. prevents breaking in LAN/NAT/Internet setups or when the server is being accessed on different IPs and or different host names)
I am still of the opinion that there are several cases where being able to *optionally* override the hostname used in dynamic replies by the one set in the config does make sense.
* reverse proxies (although not recommended) might access the icecast server by only internally resolving host-names. This would deliver the client a broken generated playlist file.
* some server admins want to force a _single_ and _specific_ host name to be returned by the server (e.g. to ensure RRDNS, to avoid unauthorized 3rd parties defining FQDN for the server and having the server _return_ that unauthorized FQDN in dynamic playlists)
* http vs. https scenarios might break things too (e.g. different server/proxy/request-routing per port). _listenurl_ is *always* httpThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2130Add POST support to admin requests2018-10-04T10:42:35ZMarvin ScholzAdd POST support to admin requestsDue to how web stuff works and the web interface handles things (auth managements for instance) it is mandatory that we support POST, for properly sending data to the server.
(Just one downside of GET that already should be enough is th...Due to how web stuff works and the web interface handles things (auth managements for instance) it is mandatory that we support POST, for properly sending data to the server.
(Just one downside of GET that already should be enough is that the password would be in cleartext in the browser history)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2135Return "return" code for command_manageauth iceresponse2018-07-16T09:12:54ZMarvin ScholzReturn "return" code for command_manageauth iceresponseReturn "return" code in iceresponse for command_manageauth, to indicate if it failed or succeeded.Return "return" code in iceresponse for command_manageauth, to indicate if it failed or succeeded.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1936Add <audio> and <video> elements to supported streams on status page.2018-06-16T22:37:50ZThomas B. RückerAdd <audio> and <video> elements to supported streams on status page.Now that Firefox will ship with fixed chaining we can push this much more.
By supported I mean at least: vorbis, Opus, theora, WebMNow that Firefox will ship with fixed chaining we can push this much more.
By supported I mean at least: vorbis, Opus, theora, WebMIcecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/595fallback management in /admin/ interface2018-06-15T21:35:14ZMike Altrionfallback management in /admin/ interfaceIt would be nice to see and manage in the admin interface what fallback mountpoint was configured for a given mountpoint.It would be nice to see and manage in the admin interface what fallback mountpoint was configured for a given mountpoint.Michael SmithMichael Smith