Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2022-02-28T11:17:41Zhttps://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/2408Rename <no-mount>2022-02-28T10:58:49ZPhilipp SchafftRename <no-mount>The config option `<no-mount>` should be renamed to have some better name.
One of the suggestions was `<allow-direct-access>` (which has inverted logic).The config option `<no-mount>` should be renamed to have some better name.
One of the suggestions was `<allow-direct-access>` (which has inverted logic).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2398Handling of GET request on admin/ should be updated2020-10-15T15:24:33ZPhilipp SchafftHandling of GET request on admin/ should be updatedCurrently GET request are handled alike POST request. This should be changed to the following:
In operation mode `legacy`: \
Keep as is.
In operation mode `normal`: \
Write a warning about such clients.
In operation mode `strict`: \
R...Currently GET request are handled alike POST request. This should be changed to the following:
In operation mode `legacy`: \
Keep as is.
In operation mode `normal`: \
Write a warning about such clients.
In operation mode `strict`: \
Reject the request.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2384Internalization2023-01-03T10:23:47ZMejansInternalizationHello,
could it be possible to have a language manager so we can display web pages in different languages?Hello,
could it be possible to have a language manager so we can display web pages in different languages?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2369Allow for master list to contain authentication credentials (when consumed by...2021-07-26T16:00:10ZThomas B. RückerAllow for master list to contain authentication credentials (when consumed by relay client)Extension of functionality merged as part of #1878
Add handling of auth credentials as part of URL.Extension of functionality merged as part of #1878
Add handling of auth credentials as part of URL.Philipp SchafftPhilipp Schaffthttps://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/2359`<listen-socket>` does not support `<http-headers>`2020-10-15T20:42:13ZPhilipp Schafft`<listen-socket>` does not support `<http-headers>`Currently `<listen-socket>` does not support `<http-headers>` as a child. While I see little reason to use this there is no reason why this should not work.Currently `<listen-socket>` does not support `<http-headers>` as a child. While I see little reason to use this there is no reason why this should not work.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2358Improve Icecast's logging of developer only messages2019-04-23T13:54:32ZPhilipp SchafftImprove Icecast's logging of developer only messagesCurrently Icecast logs many details that are only of interest to developers. Those lines "spam" the error log.
There should be a way to disable those messages. This could happen using the well-known DEBUG macro OR by adding another log ...Currently Icecast logs many details that are only of interest to developers. Those lines "spam" the error log.
There should be a way to disable those messages. This could happen using the well-known DEBUG macro OR by adding another log level or log flag (as those messages may themself have different log levels as per their logic).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2354Improve way of what URI is sent to YP2022-03-21T23:14:53ZPhilipp SchafftImprove way of what URI is sent to YPAt this point the URI sent to YP servers is based on the hostname and global port setting. However this does not work with TLS enabled and may not work for more complex setups with internal-/external-split (including different hostnames)...At this point the URI sent to YP servers is based on the hostname and global port setting. However this does not work with TLS enabled and may not work for more complex setups with internal-/external-split (including different hostnames).
An attribute to the `<directory>` tag should be added that takes the ID of a `<listen-socket>` on which behalf the YP submission should be made. That `<listen-socket>` may be `type="virtual"`.
See: #2171Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2348Auth backend for enforcing initial 4012019-04-23T13:54:32ZPhilipp SchafftAuth backend for enforcing initial 401There should be an auth backend that enforces an initial 401 reply.
This would be useful to off-load generation of those initial replies from other backends such as the URL auth backend.
This works by:
```
If (!user || !password) {
...There should be an auth backend that enforces an initial 401 reply.
This would be useful to off-load generation of those initial replies from other backends such as the URL auth backend.
This works by:
```
If (!user || !password) {
return failed;
} else {
return no match;
}
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2347ACL should support names2020-10-15T14:20:49ZPhilipp SchafftACL should support namesACLs should support name=""s just like Roles do for easier administration.
This will become more important when Icecast will support multiple ACLs per Role.ACLs should support name=""s just like Roles do for easier administration.
This will become more important when Icecast will support multiple ACLs per Role.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2343Add API endpoint to sets a mark in the log files2020-10-02T13:37:21ZPhilipp SchafftAdd API endpoint to sets a mark in the log filesThis is for debugging. The endpoint would write marker into the log file. This can be helpful to find things in busy logfiles more easily.
The marker could optionally include a user provided string and username+role of the user who requ...This is for debugging. The endpoint would write marker into the log file. This can be helpful to find things in busy logfiles more easily.
The marker could optionally include a user provided string and username+role of the user who requested the mark.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2340authentication subsystem should allow the user to send a custom error2018-10-16T06:39:31ZPhilipp Schafftauthentication subsystem should allow the user to send a custom errorThe authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="a...The authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="anonymous" deny-all="*" reject-with="f955b6c6-aaca-4734-aacc-67d86bf83c3b" />
</authentication>
```
This would also be in-line with `AUTH_ALTER_SEND_ERROR`.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2225Make listen backlog customizable2018-09-28T14:05:00ZMarvin ScholzMake listen backlog customizableExcerpt from a mail we got on the list:
On 02/19/2015 03:07 PM, Stephan Leemburg wrote:
> I am working for the NPO, the Dutch Public Broadcasting agency.
>
> We do a lot of icecast streaming. We run at least 20 icecast server
> instanc...Excerpt from a mail we got on the list:
On 02/19/2015 03:07 PM, Stephan Leemburg wrote:
> I am working for the NPO, the Dutch Public Broadcasting agency.
>
> We do a lot of icecast streaming. We run at least 20 icecast server
> instances on our media streaming cluster. [...]
>
> We ran into an issue that clients which where connecting to our streams
> seemed to be 'hanging' on the connection setup frequently. The client
> 'thinks' it is connected, but no data.
>
> People suggested that it probably had to do with the poll() call. So, I
> looked into that.
>
> I found that the issue was actually caused by the very low listen
> backlog (5).
> On our clusters, we typically set this to 8192. Yes it is high, but we
> do a _lot_ of streaming and host very high volume websites.
Attached are the submitted patches for 2.4, 2.5 and 2.3.3
Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2192URL auth: override status code and send custom headers2018-09-28T15:04:52ZThomas B. RückerURL auth: override status code and send custom headersCurrently we're hardcoded to 401, if the backend refuses authentication. 403 might also be desireable or 30x with a _location_ header.
This needs two things:
* capability to set a custom status (including message)
* capability to send...Currently we're hardcoded to 401, if the backend refuses authentication. 403 might also be desireable or 30x with a _location_ header.
This needs two things:
* capability to set a custom status (including message)
* capability to send headers that will be forwarded to the client
The latter can also be used to set cookies, so is useful by itself.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2173Max duration support for stream dumpfiles2022-03-22T17:48:23ZThomas B. RückerMax duration support for stream dumpfilesWe've received a request on this topic:
```
My suggestion is that the dump-file tag have an interval option or tag so
that it creates a new dump file based on this interval, and named based
on some sort of dump-file-name tag which wou...We've received a request on this topic:
```
My suggestion is that the dump-file tag have an interval option or tag so
that it creates a new dump file based on this interval, and named based
on some sort of dump-file-name tag which would use BASH naming variables
to name it.
```
http://lists.xiph.org/pipermail/icecast/2015-March/013209.html
Basically boils down to setting a duration and after that reopening the dump file. We already support strftime patterns in the file name.
I have received a patch for this against 2.3.2 and we'll evaluate if it can be reused or at least used as inspiration.
Optional related feature: dump files triggered / turned on/off through admin request.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1944Rework STATS interface2018-10-18T08:01:51ZcatoRework STATS interfaceThe current STATS interface which can be accessed via "curl -X STATS http://server:8000/" lacks some features:
1) Not compliant with HTTP spec:
- method needs to be changed from STATS to GET and with
that the target URL has also ...The current STATS interface which can be accessed via "curl -X STATS http://server:8000/" lacks some features:
1) Not compliant with HTTP spec:
- method needs to be changed from STATS to GET and with
that the target URL has also to be changed
- Sent HTTP-Response headers, define mime-type
2) Add lines for mount add/remove, for example "ADD /test.ogg" and "REMOVE /test.ogg"
3) Remove spurious "null null" entries
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1655OggFLAC metadata not supported in Icecast2022-03-16T01:33:34ZJim CollinsonOggFLAC metadata not supported in IcecastAs a business we would really like to start streaming in lossless OggFLAC, but Icecast does not support metadata from OggFLAC. So this is a no-go for us at the moment.
FLAC uses Vorbis comments, so surly this wouldn't be difficult to ac...As a business we would really like to start streaming in lossless OggFLAC, but Icecast does not support metadata from OggFLAC. So this is a no-go for us at the moment.
FLAC uses Vorbis comments, so surly this wouldn't be difficult to achieve?Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1296Freeze Metadata2018-11-08T14:02:57ZGitlab BotFreeze Metadatait will be cool if i can myself determine artist or title that will be seen in winamp while streaming it can be done for example
<mount>
<mount-name>/Mount</mount-name>
<password>password</password>
<artist-name>...it will be cool if i can myself determine artist or title that will be seen in winamp while streaming it can be done for example
<mount>
<mount-name>/Mount</mount-name>
<password>password</password>
<artist-name> Artist name </artist-name>
</mount>
and in winamp i will see "Artist name" (current song that is playing) it is very usefull when u don`t want listeners to see names of tracks and ur streaming program can`t off sending metadata for example virtual dj or tractor
Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1195StreamTitle Template for Icecast 22018-11-08T14:02:03ZscratchStreamTitle Template for Icecast 2In Icecast 1 it seemed to be possible to append or prepend a string to a title using a StreamTitle template (this is also possible in shoutcast):
for example:
[yourRadioName] %s
became
[yourRadioName] Some Artist - Some Title
I am not ...In Icecast 1 it seemed to be possible to append or prepend a string to a title using a StreamTitle template (this is also possible in shoutcast):
for example:
[yourRadioName] %s
became
[yourRadioName] Some Artist - Some Title
I am not a coder, and i think icecast2 is Great (good work),
but since it was possible before, I think it shouldn't be so hard
to be able to modify that metadata before icecast sends it to the listeners.
I know you can set such options in a source client, but as you have many djs or channels with their own setups, it provides a standard in the title format. Also, when you would want to set up a commercial service, all stations could be marked with your "powered by".Icecast 2.5.0Michael SmithMichael Smith