Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-03-06T12:49:47Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2146Icecast should send the "admin" field from config to YP2018-03-06T12:49:47ZThomas B. RückerIcecast should send the "admin" field from config to YPThis would allow the YP admins to contact the server administrator in case of problems with the listing/streams.
It would address a very common problem, finding out the contact details for a server admin.This would allow the YP admins to contact the server administrator in case of problems with the listing/streams.
It would address a very common problem, finding out the contact details for a server admin.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2144Icecast might hang with 100% cpu use upon failed startup2018-10-27T11:17:45ZThomas B. RückerIcecast might hang with 100% cpu use upon failed startupI just ran into it again. It looks like it gets caught up in waiting for something.
Example output when trying to bind to inexistent IPv4 address:
```
$ /usr/bin/icecast -c /etc/icecast.xml
[2015-01-08 05:21:48] EROR connection/connec...I just ran into it again. It looks like it gets caught up in waiting for something.
Example output when trying to bind to inexistent IPv4 address:
```
$ /usr/bin/icecast -c /etc/icecast.xml
[2015-01-08 05:21:48] EROR connection/connection_setup_sockets Could not create listener socket on port 8000 bind 203.0.113.23
[2015-01-08 05:21:48] EROR connection/connection_setup_sockets No listening sockets established
Server startup failed. Exiting
```
"strace -f" doesn't produce any output after writing that last message.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2143Regresion: reloadconfig* got de-linked on redesign of admin intrerface2018-03-06T12:49:47ZPhilipp SchafftRegresion: reloadconfig* got de-linked on redesign of admin intrerfaceLinks to the reloadconfig-admin command got lost on update of the design. Those should be re-linked.Links to the reloadconfig-admin command got lost on update of the design. Those should be re-linked.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2133Regression: Role management not possible via admin interface2018-03-06T12:49:47ZPhilipp SchafftRegression: Role management not possible via admin interfaceRole management via admin/ interface is currently not possible as there is no lists of roles displayed. listings of roles must be implemented so user can find the right link to the management page.Role management via admin/ interface is currently not possible as there is no lists of roles displayed. listings of roles must be implemented so user can find the right link to the management page.Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://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/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/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/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/2082Require content-type for PUT connections2018-03-06T12:49:47ZThomas B. RückerRequire content-type for PUT connectionsWe should only allow PUT connections if the content-type is explicitly set.
This will avoid breakage such as a source sending a ogg/vorbis stream, but not setting a content-type and then being mis-listed as "audio/mpeg" instead of "audio...We should only allow PUT connections if the content-type is explicitly set.
This will avoid breakage such as a source sending a ogg/vorbis stream, but not setting a content-type and then being mis-listed as "audio/mpeg" instead of "audio/ogg".
This will need to be made very clear in release notes and documentation, so that people are aware when writing new clients or porting old clients to the PUT protocol to properly set content-type.
We can't enforce this for SOURCE connections as there are simply too many broken clients out there.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2081Wrong duration value in access.log on mingw32 builds2018-03-06T12:49:47ZThomas B. RückerWrong duration value in access.log on mingw32 builds34678888 or such (jitter in the last 4-5 digits) for static files from the web interface that were served in under a second is rather unlikely.
On the mailing list someone reported also weird values in case of longer connections.
Teste...34678888 or such (jitter in the last 4-5 digits) for static files from the web interface that were served in under a second is rather unlikely.
On the mailing list someone reported also weird values in case of longer connections.
Tested on Windows 2012 R2Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2080Limit/Filter access types available through a listener socket2018-10-02T08:29:07ZThomas B. RückerLimit/Filter access types available through a listener socketOne thing that might be worth considering is to add another setting to listener sockets that would limit which requests are handled on that port.
Listener clients, POST/sources, admin, STATS, XSLT, static files - come to mind.
Especial...One thing that might be worth considering is to add another setting to listener sockets that would limit which requests are handled on that port.
Listener clients, POST/sources, admin, STATS, XSLT, static files - come to mind.
Especially in case of professional installations there is often the desire to limit exposure to potential attacks to a minimum.
That way there could be a listener client port on public IP, while all advanced functionality would only be available on a firewalled IP/port.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2077Stats data in iso8601 fields on mingw32 builds is wrong.2018-03-06T12:49:47ZThomas B. RückerStats data in iso8601 fields on mingw32 builds is wrong.We're using %z, which isn't consistent with other platforms. It depends on system configuration but could be a textual representation of the time zone or the time zone offset. The latter is what we want.
There is a workaround in our log...We're using %z, which isn't consistent with other platforms. It depends on system configuration but could be a textual representation of the time zone or the time zone offset. The latter is what we want.
There is a workaround in our logging code for this, which should be applied here too.Icecast 2.5.0