Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-03-06T12:49:47Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2125Kicking a source disconnects listeners even if fallback defined2018-03-06T12:49:47ZThomas B. RückerKicking a source disconnects listeners even if fallback definedAs mentioned by ph3-der-loewe, this seems to happen. One would expect that if a source is forcefully disconnected, that the listeners are sent to defined fallbacks.As mentioned by ph3-der-loewe, this seems to happen. One would expect that if a source is forcefully disconnected, that the listeners are sent to defined fallbacks.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2124With <role> every client needs to go thru the stack of auth_ts. This will del...2018-03-06T12:49:47ZPhilipp SchafftWith <role> every client needs to go thru the stack of auth_ts. This will delay client connectionsEvery client is now forced to auth. As currently each <role> is implemented with a independent thread and queue this may take extra time. also some modules such as the static type can tell with like no delay if a user matches and does no...Every client is now forced to auth. As currently each <role> is implemented with a independent thread and queue this may take extra time. also some modules such as the static type can tell with like no delay if a user matches and does not need the asynchronous handling of a thread.
I suggest to build an interface so the type cann tell if they need the asynchronous interface or if a synchronous interface will do.
This would reduce the number of threads by at least one per process plus one per password (non-htpasswd) auth. If htpasswd auth can be converted is to be checked.
I suspect a massive performance improvement by this.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2123Support management of multiple <role>s2018-03-06T12:49:47ZPhilipp SchafftSupport management of multiple <role>sAs with <role> support there can be multiple per <mount> and global <role>s management support in the admin/ interface needs update.
there are 3 most major parts of this:
1. defining format and outputting information about those <role>s...As with <role> support there can be multiple per <mount> and global <role>s management support in the admin/ interface needs update.
there are 3 most major parts of this:
1. defining format and outputting information about those <role>s on a given (mount or global) object.
1. update the admin/*.xsl files to reflect the new interface.
1. update command_manageauth() to reflect the changes.
Please define a format for the output and reassign to me after that.
Examples:
```
<authentication>
<role id="xxx" name="yyy" />
<role id="xxx" name="yyy" />
<role id="xxx" name="yyy" />
</authentication>
```
```
<authentication>
<role>
<id>yyy</id>
<name>xxx</name>
</role>
<role>
<id>yyy</id>
<name>xxx</name>
</role>
<role>
<id>yyy</id>
<name>xxx</name>
</role>
</authentication>
```
The first example mimics the config file format. The second is more to how stuff in admin/* has been.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2122README.md needs minor fixes2018-03-06T12:49:47ZThomas B. RückerREADME.md needs minor fixese.g. webm and opus missing
Also this ticket will serve for testing git to trac hooks.e.g. webm and opus missing
Also this ticket will serve for testing git to trac hooks.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2121doc subdirectories don't work if packaging overrides "docdir"2018-03-06T12:49:47ZThomas B. Rückerdoc subdirectories don't work if packaging overrides "docdir"Case in point: debian
Patch is in the works as I need it also for my deb/RPM packaging on OBS.Case in point: debian
Patch is in the works as I need it also for my deb/RPM packaging on OBS.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2119Filter based on User Agent2018-11-10T13:31:06ZPhilipp SchafftFilter based on User AgentThere is `<allow-ip>` and `<deny-ip>` already. Someone was asking me for a way to filter clients based on User Agents.
I would suggest to implement this as a role-type. This should allow matching on all headers and maybe on other kinds ...There is `<allow-ip>` and `<deny-ip>` already. Someone was asking me for a way to filter clients based on User Agents.
I would suggest to implement this as a role-type. This should allow matching on all headers and maybe on other kinds of client data as well.
The module would return `NOMATCH` on no match or `FAILED` on match on deny list. Behaviour on pass should maybe be documented. Defaulting to `NOMATCH` to continue with the processing of other `<role>`s.
Some technical background:
In contrast to the `<allow-ip>` and `<deny-ip>` this check can only happen after the client request has been parsed as it depends on data of exactly this client request. This makes it less suitable for (D)DoS protection in general. It should be considered to use some kind of firewalling of fail2ban to protect against such attacks.
Pros of implementing it the way described above:
- It would match the internal schemata and wouldn't be another alien.
- It could be extended to universally match any configured attributes of the client object.
- Integrates well into usage together with other `<role>`s. E.g. to allow some role access but deny others access depending on this module (admin can always go, listeners only if user agent matches).
- Rejects the client with a `401` according to the standard.
Contra:
- Is much slower than implementing it in a specific and specific way as it happens in the authentication engine and not in before on rejected clients. Slowdown for passing clients will not be significant.
- Rejects clients with a standard conforming `401`. Does not just drop them.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2117Creating a policy for removing support for obsoleted features/interfaces2018-06-16T22:40:11ZPhilipp SchafftCreating a policy for removing support for obsoleted features/interfacesThere needs to be a policy that tells when and how to remove a feature or interface that has been obsoleted for some reason. This policy will become very important when moving forward. Icecast recently had some major changes that move th...There needs to be a policy that tells when and how to remove a feature or interface that has been obsoleted for some reason. This policy will become very important when moving forward. Icecast recently had some major changes that move the internals away from how 2.3.2 was. Such a policy will help much to avoid keeping workarounds for older ways of doing stuff in the codebase and will be a major improvement to the code quality and maintainability.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2116Write FAQ on how to set <hostname> correctly2022-03-21T09:35:20ZPhilipp SchafftWrite FAQ on how to set <hostname> correctlyAs we introduced checks for <hostname> and may going to be more strict with this over time documentation needs to be updated.
- Check if documentation tells about setting this to an IP address anywhere. If so correct this.
- Write a sma...As we introduced checks for <hostname> and may going to be more strict with this over time documentation needs to be updated.
- Check if documentation tells about setting this to an IP address anywhere. If so correct this.
- Write a small FAQ on setting <hostname> correctly. This should be mostly for those who aren't familiar with the concept of hostnames.
Some ideas for the FAQ:
- Tell what a hostname, a FQDN is and how it is related and more importantly not related to IP addresses.
- Include a hint to use same domain as webpage.
- Include hint for falling back to whatever server hoster use a default hostname.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2104Check: Bytes sent and time listening might be broken?2018-10-04T10:54:41ZMarvin ScholzCheck: Bytes sent and time listening might be broken?> logging - bytes send and time listening may both be broken?
As mentioned in the TODO file, we should check this.
> logging - bytes send and time listening may both be broken?
As mentioned in the TODO file, we should check this.
Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2101Verify if on-connect (events) are still impossible on windows2018-03-06T12:49:38ZThomas B. RückerVerify if on-connect (events) are still impossible on windowsWe migrated to mingw32, I suspect it might now be either trivial or easy to fork a script (.bat). We migrated to mingw32, I suspect it might now be either trivial or easy to fork a script (.bat). Icecast 2.6Stephan JauernickStephan Jauernickhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2100Document icecast access log format in docs2018-03-06T12:49:38ZThomas B. RückerDocument icecast access log format in docswe should explain it, especially the last field that adds on top of Apache "combined" type output and signifies connection duration in seconds.
Also mentioning that we do NOT log the amount of data sent by a source client due to adherin...we should explain it, especially the last field that adds on top of Apache "combined" type output and signifies connection duration in seconds.
Also mentioning that we do NOT log the amount of data sent by a source client due to adhering to convention "bytes _sent_".Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2099Review how Icecast binds to sockets (IPv6/IPv4)2022-03-07T10:07:56ZThomas B. RückerReview how Icecast binds to sockets (IPv6/IPv4)The current behaviour, as introduced after considerable research and discussion neeeds to be reviewed.
Either we should bind to *both* if no IP nor protocol is specified or we MUST document this better and change the default config to e...The current behaviour, as introduced after considerable research and discussion neeeds to be reviewed.
Either we should bind to *both* if no IP nor protocol is specified or we MUST document this better and change the default config to explicitly bind to both.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2097In <listener> in some tags are camelcase that should be converted to lowercase.2018-03-06T12:49:47ZPhilipp SchafftIn <listener> in some tags are camelcase that should be converted to lowercase.in <listener> the following tags are camelcase: <ID>, <IP>, <UserAgent> and <Connected>. Those should be converted to lower case.
XML tells that tag names are case sensitive.
This needs to be documented before we can change it and be cha...in <listener> the following tags are camelcase: <ID>, <IP>, <UserAgent> and <Connected>. Those should be converted to lower case.
XML tells that tag names are case sensitive.
This needs to be documented before we can change it and be changed with a major release. I suggest to document it as 'Parsers MUST be case insensitive for ALL tags in ANY admin/-command output.'
```
09:51 <+tbr> as a broad statement, I'd not expect this change to happen before 2.6
09:52 < ph3-der-loewe> I haven't thought about a timeline for that already.
09:52 < ph3-der-loewe> I'm fine with <= 3.0.0 :)
09:53 < ph3-der-loewe> with 3.0.0 the question that arise is if the interface still exist ;)
```
Please review this before 2.5 to check if we are on-track on this.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2094YP protocol documentation / revision2018-03-06T12:49:38ZThomas B. RückerYP protocol documentation / revisionWe should document the currently used YP protocol, old docs might be available but are outdated.
As we'll have to introduce a few changes we should rethink some protocol aspects while we document it.
Collaborative wiki page is at https...We should document the currently used YP protocol, old docs might be available but are outdated.
As we'll have to introduce a few changes we should rethink some protocol aspects while we document it.
Collaborative wiki page is at https://wiki.xiph.org/Icecast/YP-protocol-v2Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2092Write specification of Icecast specific HTTP protocol features2018-06-07T20:52:20ZThomas B. RückerWrite specification of Icecast specific HTTP protocol featuresUse HTTP 1.0 and 1.1 specs as base, document differences and quirks.
Give guidance what a source client SHOULD, MUST, MUST NOT do, etc.
Explain source and listener HTTP headers, authentication quirks.Use HTTP 1.0 and 1.1 specs as base, document differences and quirks.
Give guidance what a source client SHOULD, MUST, MUST NOT do, etc.
Explain source and listener HTTP headers, authentication quirks.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2091Fix up ogg serial numbers for incoming streams in Icecast2018-03-06T12:49:38ZThomas B. RückerFix up ogg serial numbers for incoming streams in IcecastWe should do this server side, there are too many broken things out there.
Ices has some code for this if we need a reference.We should do this server side, there are too many broken things out there.
Ices has some code for this if we need a reference.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2088accept data with “Transfer-Encoding: chunked”2018-03-06T12:49:47ZSven Herzbergaccept data with “Transfer-Encoding: chunked”Many HTTP frameworks will automatically encode data streams using the aforementioned method. I propose this behavior for Icecast:
* check if the protocol is not `HTTP/1.1` or there is no `Transfer-Encoding` header, continue as in the pa...Many HTTP frameworks will automatically encode data streams using the aforementioned method. I propose this behavior for Icecast:
* check if the protocol is not `HTTP/1.1` or there is no `Transfer-Encoding` header, continue as in the past (i.e. assume `identity` encoding)
* if the `Transfer-Encoding` header is present and it is `identity`, continue as in the past
* if the `Transfer-Encoding` header is present and it is `chunked`, accept the data and strip the encoding information both from the output stream and from the dumpfile
* if the `Transfer-Encoding` header is present and has a different value, terminate the request with 501 (Unimplemented) and provide an HTTP response body listing the supported encodings (in case developers need to debug this).
That behavior in compliant with RFC2616 (Section 3.6) and RFC7230 (Section 3.3.1).Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2087icecast does not only write the stream data into the dumpfile2018-03-06T12:49:47ZSven Herzbergicecast does not only write the stream data into the dumpfileHow to reproduce:
Write a script (e.g. called “test-script.sh”) with this content and set the executable bit:
```
set -e
set -x
echo "stdout"
echo "stderr" >&2
```
Then specify that script in an mount point of the icecast configurat...How to reproduce:
Write a script (e.g. called “test-script.sh”) with this content and set the executable bit:
```
set -e
set -x
echo "stdout"
echo "stderr" >&2
```
Then specify that script in an mount point of the icecast configuration like this (I have this in my mount point defaults):
```
<on-connect>/path/to/test-script.sh</on-connect>
```
The beginning of the dump-file will look like this:
```
# hexdump -C /srv/icecast/test-stream/backup.mp3 | head
00000000 2b 20 65 63 68 6f 20 73 74 64 6f 75 74 0a 2b 20 |+ echo stdout.+ |
00000010 65 63 68 6f 20 73 74 64 65 72 72 0a 73 74 64 65 |echo stderr.stde|
00000020 72 72 0a 2b 20 65 78 69 74 20 30 0a […] |rr.+ exit 0.[…]|
```
This makes the dumpfiles difficult to use as backups of the stream data.
I think the `<errorlog>` target would be more a appropriate target for this output.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2085Removal of <threadpool>2018-11-09T14:06:15ZPhilipp SchafftRemoval of <threadpool><threadpool> should be removed as it is no longer in use.
I suggest to add a ERROR level message on usage in 2.4.2 informing the user about this.
Then I suggest that we remove the setting completely in 2.5.0, not before in about one year.<threadpool> should be removed as it is no longer in use.
I suggest to add a ERROR level message on usage in 2.4.2 informing the user about this.
Then I suggest that we remove the setting completely in 2.5.0, not before in about one year.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2084Add support for ANSI streaming2021-10-26T09:40:29ZPhilipp SchafftAdd support for ANSI streamingStreaming in Text+ANSI Codes should be added to icecast. This would allow to to send shows of e.g. text adventures or other text games and applications.Streaming in Text+ANSI Codes should be added to icecast. This would allow to to send shows of e.g. text adventures or other text games and applications.Icecast 2.6