Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-03-06T12:49:38Zhttps://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/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/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.6https://gitlab.xiph.org/xiph/icecast-server/-/issues/2074symlink icecast docs into web dir during install2018-03-06T12:49:39ZThomas B. Rückersymlink icecast docs into web dir during installThis would make the docs much more discoverable for the average user.
We could then simply link to them from the status page and the admin pages.
Docs are already HTML as we also expose them through http://icecast.org/docs/ for each ver...This would make the docs much more discoverable for the average user.
We could then simply link to them from the status page and the admin pages.
Docs are already HTML as we also expose them through http://icecast.org/docs/ for each version
On Windows it would be a full copy instead.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2073Turn on Forward Secrecy in openSSL support2022-03-21T09:33:34ZThomas B. RückerTurn on Forward Secrecy in openSSL supportThis would further improve security in case of HTTPS usage.
This will need a patch to configure the curve to be used.
cf.
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
https://github.com/bumptech/stud/pull/61/...This would further improve security in case of HTTPS usage.
This will need a patch to configure the curve to be used.
cf.
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
https://github.com/bumptech/stud/pull/61/filesIcecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2056On-demand relay mount vanishes shortly right after last player disconnects2023-02-27T11:40:50ZMarvin ScholzOn-demand relay mount vanishes shortly right after last player disconnectsIf a on demand relay is configured, and the last listener disconnects, it vanishes from the stats for a short period of time.
This is because in `source.c` the `source_shutdown()` function deletes the source stats:
```
stats_event(so...If a on demand relay is configured, and the last listener disconnects, it vanishes from the stats for a short period of time.
This is because in `source.c` the `source_shutdown()` function deletes the source stats:
```
stats_event(source->mount, NULL, NULL);
```
There would be different approaches to fix this:
1. Do not fix it at all
2. If it is a on-demand mount, only remove the data that will probably change
3. Remove all data and trigger immediate refresh of mount data (inefficient?)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2055Changing relay on-demand settings messes things up2018-03-06T12:49:38ZMarvin ScholzChanging relay on-demand settings messes things upIf a relay is configure in Icecast like the following:
```
<relay>
<server>stream.server.de</server>
<port>8000</port>
<mount>/24.mp3</mount>
<local-mount>/diff.mp3</local-mount>
<relay-shoutcast...If a relay is configure in Icecast like the following:
```
<relay>
<server>stream.server.de</server>
<port>8000</port>
<mount>/24.mp3</mount>
<local-mount>/diff.mp3</local-mount>
<relay-shoutcast-metadata>0</relay-shoutcast-metadata>
<on-demand>1</on-demand>
</relay>
```
and the `on-demand` value is changed to 0 and config re-read with SIGHUP, it will still show as on-demand in the stats and the whole relay mount will disappear and reappear quite randomly.
When initially 0 and changed to 1 it seems to have no effect at all.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2004calls to abort() should be removed and checks for memory allocation failture ...2018-10-18T08:03:57ZPhilipp Schafftcalls to abort() should be removed and checks for memory allocation failture to be addedicecast calls abort() 3 times. All 3 times are related to memory allocation. It is used to avoid the need to handle errors on memory allocation. In many other places memory allocation is not checked to be successful.
* all calls to abor...icecast calls abort() 3 times. All 3 times are related to memory allocation. It is used to avoid the need to handle errors on memory allocation. In many other places memory allocation is not checked to be successful.
* all calls to abort() should be removed.
* all calls to malloc(), calloc() and realloc() should be checked handling errors correctly.
* There should be a policy on what happens on memory allocation failure (icecast dropping clients/resources OR dieing?)
* icecast should (at high/all cost) try to inform the user about this problem.
* memory failure can have many reasons. Not just the system being out of memory.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2003refbuf should be replaced2018-10-18T08:03:57ZPhilipp Schafftrefbuf should be replacedrefbuf is a type of objected used to store binary data. As the name suggest it has an internal reference counter that allows it to be freed automatically when no longer in use.
the old refbuf objects aren't well designed and allow direc...refbuf is a type of objected used to store binary data. As the name suggest it has an internal reference counter that allows it to be freed automatically when no longer in use.
the old refbuf objects aren't well designed and allow direct access to internal data structures. This became abused.
The new object type MUST:
* be well designed,
* not allow access to internal data structures,
* have a well designed API to access the object's content in a secure way.Icecast 2.6Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1973Allow standard HTTP method instead of non-standard "STATS" for opening stats ...2023-01-28T20:46:15ZjA_cOpAllow standard HTTP method instead of non-standard "STATS" for opening stats streamMany HTTP libraries don't support using non-standard HTTP methods, so this can be a blocking issue.
Many HTTP libraries don't support using non-standard HTTP methods, so this can be a blocking issue.
Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1959Icecast to accept custom REMOTE IP headers for reverse proxy compatibility.2022-11-10T18:58:16ZYahavIcecast to accept custom REMOTE IP headers for reverse proxy compatibility.Would be nice to be able to set a custom header name in the config in which Icecast will check for the remote ip address.
(<IP-HEADER>X-Forwarded-For</IP-HEADER>)
will be useful with reverse proxying and such.
(Implemented in KH-2.3.3-kh...Would be nice to be able to set a custom header name in the config in which Icecast will check for the remote ip address.
(<IP-HEADER>X-Forwarded-For</IP-HEADER>)
will be useful with reverse proxying and such.
(Implemented in KH-2.3.3-kh1: http://karlheyes.github.io ) Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1941fallback support in webm2019-06-26T17:23:34Zocxfallback support in webmDear Community,
We noticed that the fallback stream for webm is not working fine, we included a file named fallback.webm in /usr/local/share/icecast/web
if we try to access the stream when no source is connected we get the following err...Dear Community,
We noticed that the fallback stream for webm is not working fine, we included a file named fallback.webm in /usr/local/share/icecast/web
if we try to access the stream when no source is connected we get the following error:
[2013-03-28 00:14:45] INFO source/source_main listener count on /fallback.webm now 1
[2013-03-28 00:14:45] EROR format/format_check_http_buffer internal problem, dropping client
[2013-03-28 00:14:45] INFO source/source_main listener count on /fallback.webm now 0
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1938timelimit_header is not considered for stream_auth2018-03-06T12:49:39Zcatotimelimit_header is not considered for stream_authProblem:
A url is configured for stream_auth to limit the authentication for sources. The configured URL returns a "icecast-auth-timelimit: 600"-header, but the source does not get disconnected after 10 minutes.Problem:
A url is configured for stream_auth to limit the authentication for sources. The configured URL returns a "icecast-auth-timelimit: 600"-header, but the source does not get disconnected after 10 minutes.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1902Icecast should implement RFC 5334 / 4281 support ("codecs" Media Type parameter)2021-10-30T09:39:38ZThomas B. RückerIcecast should implement RFC 5334 / 4281 support ("codecs" Media Type parameter)Just stumbled into this while working on Opus support in the YP server code.
Proper support for "; codecs=" as specified in RFC 5334 / 4281 in the content-type would be desireable. This could then be used to present proper information i...Just stumbled into this while working on Opus support in the YP server code.
Proper support for "; codecs=" as specified in RFC 5334 / 4281 in the content-type would be desireable. This could then be used to present proper information in the web interface and when submitting to YP. It would also provide hinting for listener clients.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ückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1880Join video streams on keyframes2018-03-06T12:49:39ZGregory MaxwellJoin video streams on keyframesFor keyframe based video (as opposed to rolling intra refresh) clients can't display output (correctly at least) until they hit a keyframe.
So it would be useful if streams started on keyframes. There are a couple options for this.
If ...For keyframe based video (as opposed to rolling intra refresh) clients can't display output (correctly at least) until they hit a keyframe.
So it would be useful if streams started on keyframes. There are a couple options for this.
If latency is unimportant and the server doesn't mind the memory usage it could buffer the span between keyframes and when a client attaches attach them back at the last keyframe. This would be like a keyframe adaptive preburst.
Alternatively, if latency matters more the server could reencode.
The best way to do this would be to constantly reencode with a very short keyframe interval (e.g. 1-12 frames) and play this out to new clients until a real keyframe comes. Optionally a 'loading' spinner could be displayed to avoid confusion from the low quality during this span. This is O(N) in the number of streams and O(1) in the number of users.
For some formats it would be possible to do some format specific smartness. E.g. in theora You could retransmit the prior keyframe timestamped as NOW-2, then reencode the prior frame (using all intra blocks at high quality) as NOW-1. Then splice in the stream. There will be some corruption until the next keyframe but it should be very minor. Unfortunately it would cause a jump in the visible output because the first frame is an old one.
Alternatively, alternatively, a pre-encoded short GOP "loading" video stream could be sent to users before the first new keyframe. Audio could be spliced in instantly however. This would avoid encoding in the icecast server.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1860[PATCH] Send credentials when doing master-relay2018-11-10T13:05:22Zcato[PATCH] Send credentials when doing master-relayWhen using a configuration with a hidden master and some relays using master-relay it should be possible to enable password protection on streams in the master icecast. Therefore it is necessary for the relaying-icecast to send credentia...When using a configuration with a hidden master and some relays using master-relay it should be possible to enable password protection on streams in the master icecast. Therefore it is necessary for the relaying-icecast to send credentials to the master-icecast. The natural choice would be to send the `<master-username>` and `<master-password>`.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1853Update graphics for Icecast documentation2018-03-06T12:49:39ZThomas B. RückerUpdate graphics for Icecast documentationRedoing some screenshots and graphics in a lossless format like PNG is desireable. Currently some are JPEG.
Please check back with dm8tbr as to when the web layout is final.
Target 2.3.3 if possible.Redoing some screenshots and graphics in a lossless format like PNG is desireable. Currently some are JPEG.
Please check back with dm8tbr as to when the web layout is final.
Target 2.3.3 if possible.Marvin ScholzMarvin Scholz