Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-10-18T08:01:51Zhttps://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/1942Spurious dots inside http request line logged to access log2018-03-06T12:49:48ZThomas B. RückerSpurious dots inside http request line logged to access log*"GET./status.xsl.HTTP/1.1"
vs
"GET /status.xsl HTTP/1.1"*"GET./status.xsl.HTTP/1.1"
vs
"GET /status.xsl HTTP/1.1"Icecast 2.4.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1939Webinterface shows Login when using just stream_auth2018-03-06T12:49:48ZcatoWebinterface shows Login when using just stream_authA stream is configured just with stream_auth. The webinterface shows an login-link anyway. Clients can still access the stream, if they use the direct link.
This happens because the xsl just looks for an authenticator for the mount, whi...A stream is configured just with stream_auth. The webinterface shows an login-link anyway. Clients can still access the stream, if they use the direct link.
This happens because the xsl just looks for an authenticator for the mount, which is "url" in this case. There is no possibility to check whether the authenticator applies for sources or for clients.Icecast 2.5.0Philipp 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/1929HTTP Content-Type doesn't autodetect and it ignores <type> and <subtype>2018-10-24T14:29:17ZEvan CarrollHTTP Content-Type doesn't autodetect and it ignores <type> and <subtype>I have a `Ogg/Opus` stream, if I don't statically put in the `<type>` and `<subtype>` into my icecast conf file `/admin/stats.xsl shows`,
```
server_type application/ogg
```
And, the HTTP header shows `application/ogg` for Content-Typ...I have a `Ogg/Opus` stream, if I don't statically put in the `<type>` and `<subtype>` into my icecast conf file `/admin/stats.xsl shows`,
```
server_type application/ogg
```
And, the HTTP header shows `application/ogg` for Content-Type. If I statically put in the `<type>` and `<subtype>` `/admin/stats.xsl` shows,
```
server_type audio/ogg
subtype opus
```
However, even statically entered the HTTP Content-Type is `application/ogg`.
Per the Opus wiki [https://wiki.xiph.org/OggOpus#Content_Type], the Content-Type should be `"audio/ogg; codecs=opus"`
> The recommended mime-type for Ogg Opus files is audio/ogg, defined in RFC 5334. If more specificity is desired, one can distinguish Opus files as 'audio/ogg; codecs=opus'. The recommended filename extension for Ogg Opus files is .opus.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1916Fix & Verify proper escaping of HTTP related variables when e.g. printing to ...2018-03-06T12:49:48ZThomas B. RückerFix & Verify proper escaping of HTTP related variables when e.g. printing to access.logSee also initial report:
http://lists.xiph.org/pipermail/icecast/2012-December/012331.html
We should check escaping for all those variables printed to access.log .See also initial report:
http://lists.xiph.org/pipermail/icecast/2012-December/012331.html
We should check escaping for all those variables printed to access.log .Icecast 2.4.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1914Port wildcard mounts to trunk2022-03-15T11:05:26ZcatoPort wildcard mounts to trunkIn the [kh-branch](https://trac.xiph.org/browser/icecast/branches/kh/icecast/src/cfgfile.c#L1203) is a feature which allows you to specify wildcard mounts like
```
<mount>
<mount-name>/foo-*.mp3</mount-name>
</mount>
```
to set options f...In the [kh-branch](https://trac.xiph.org/browser/icecast/branches/kh/icecast/src/cfgfile.c#L1203) is a feature which allows you to specify wildcard mounts like
```
<mount>
<mount-name>/foo-*.mp3</mount-name>
</mount>
```
to set options for an unknown set of mount points. Please port this to the [mainstream icecast](https://trac.xiph.org/browser/icecast/trunk/icecast/src/cfgfile.c#L1126) as well.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1913Icecast shows EROR instead of ERROR in error.log2018-03-06T12:49:48ZborlamIcecast shows EROR instead of ERROR in error.logIcecast shows EROR instead of ERROR in error.log.
error.log.4:[2012-10-25 21:00:49] EROR slave/open_relay_connection Header read failed for Icecast shows EROR instead of ERROR in error.log.
error.log.4:[2012-10-25 21:00:49] EROR slave/open_relay_connection Header read failed for Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1900Icecast errors in name resolution2020-10-02T11:59:15ZWaitman GobbleIcecast errors in name resolution(seen in Icecast 2.3.99.0 (Beta-2.4) and -HEAD)
the user _may_ see error messages such as the following in /usr/local/share/icecast/log/error.log (default location)
[2012-09-06 02:54:40] EROR yp/send_to_yp connection to http://dir.xip...(seen in Icecast 2.3.99.0 (Beta-2.4) and -HEAD)
the user _may_ see error messages such as the following in /usr/local/share/icecast/log/error.log (default location)
[2012-09-06 02:54:40] EROR yp/send_to_yp connection to http://dir.xiph.org/cgi-bin/yp-cgi failed with "Could not resolve host: dir.xiph.org; Unknown error"
This error _appears_ to be related to using the default libcurl resolver, which is blocking, in an application using pthreads. (seen in curl -v 7.27.0, *may also be an issue in other versions)
The error does *not* appear to be caused by Icecast, HOWEVER an Icecast user _may_ experience this error (which seems to be /lightly/ reported). The user may presume that Icecast has an issue. (So it might be good to mention in the documentation somewhere, or at least appear somewhere in public, such as this space, if somebody else runs into the problem and resorts to a search engine query.) Therefor, perhaps a 'documentation enhancement'.
A solution is to build curl with the c-ares resolver, which is non-blocking and asynchronous.
```
install c-ares, ie
# git clone git://github.com/bagder/c-ares.git
# cd c-ares
# ./buildconf
# ./configure
# make -j7 && make install
```
(http://c-ares.haxx.se/)
install curl
```
./configure --with-ssl=/usr/local/ssl/ --enable-ares=/usr/local
```
to check your curl install for the c-ares resolver: (note c-ares and AsynchDNS)
```
# curl --version
curl 7.27.0 (x86_64-unknown-linux-gnu) libcurl/7.27.0 OpenSSL/1.0.0g zlib/1.2.3 c-ares/1.10.0-DEV libidn/0.6.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile NTLM NTLM_WB SSL libz
```Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1896Icecast should provide xml versions of pages2018-03-06T12:49:48ZGhost UserIcecast should provide xml versions of pagesIcecast generates xml pages and then runs them through xslt to convert them to html for display. The raw xml is much more useful for people writing automation which accesses an icecast server.
While some of the raw xml files are availab...Icecast generates xml pages and then runs them through xslt to convert them to html for display. The raw xml is much more useful for people writing automation which accesses an icecast server.
While some of the raw xml files are available through the admin/ interface, this requires authentication. The same information that's available on the public stream listing and version pages should also be available as xml.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1889Error pages needs update2018-03-06T12:49:48ZPhilipp SchafftError pages needs updateThe error pages generated by icecast are currently hardcoded. Some contain invalid HTML.
Please provide a valid but very simple HTML file for the HTTP errors 400 and 404. I will also take such error pages for 401 and 403 but that has le...The error pages generated by icecast are currently hardcoded. Some contain invalid HTML.
Please provide a valid but very simple HTML file for the HTTP errors 400 and 404. I will also take such error pages for 401 and 403 but that has less priority.
The pages (except for 401) all take an string telling the user about the error. Please just leave '%s' in the 'template' where it should go.
current pages look like this:
```
<b>%s</b>
```Icecast 2.4.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1888Lower required authentification level for STATS2018-03-06T12:49:48ZcatoLower required authentification level for STATSThe STATS interface currently needs admin previleges. If you want to give an external entity access to the STATS interface you have to give them your admin password and therefore the control over the whole server. Requiring just e.g. rel...The STATS interface currently needs admin previleges. If you want to give an external entity access to the STATS interface you have to give them your admin password and therefore the control over the whole server. Requiring just e.g. relay previleges for the STATS interface would solve this.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1886[PATCH]Icecast should log to STDERR if it can't log to the errorlog file2018-03-06T12:49:48ZThomas B. Rücker[PATCH]Icecast should log to STDERR if it can't log to the errorlog fileThis would be very helpful for troubleshooting startup problems.
Likely to be implemented in log_write() or _log_open() in log/log.c.This would be very helpful for troubleshooting startup problems.
Likely to be implemented in log_write() or _log_open() in log/log.c.Icecast 2.5.0https://gitlab.xiph.org/xiph/icecast-server/-/issues/1885Icecast should allow manual HTTP header configuration2018-03-06T12:49:48ZThomas B. RückerIcecast should allow manual HTTP header configurationOne use case is: "Cross-origin resource sharing" which mandates
"Access-Control-Allow-Origin: http://example.com:8080"
Allowing CORS would simplify inclusion of custom XSLT (e.g. metadata) into other webservices.One use case is: "Cross-origin resource sharing" which mandates
"Access-Control-Allow-Origin: http://example.com:8080"
Allowing CORS would simplify inclusion of custom XSLT (e.g. metadata) into other webservices.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1879Sources should be able to specify the latency they want2018-03-06T12:49:48ZGregory MaxwellSources should be able to specify the latency they wantIcecast has a lot of options to trade off latency vs smoothness, e.g. pre-burst, and will probably have more in the future.
It is _really_ _really_ annoying to have an interactive live stream, e.g. where people are responding in realtim...Icecast has a lot of options to trade off latency vs smoothness, e.g. pre-burst, and will probably have more in the future.
It is _really_ _really_ annoying to have an interactive live stream, e.g. where people are responding in realtime over IRC or other streams where the pre-burst is adding 5 seconds of delay. And it's a pain to go get access to the icecast server in order to turn off these features, as the server operator may not be easily available.
The stream source knows best if low latency is required. To the extent that the high latency features impact server scaling it may be useful if the server can still limit them, but absent forcing on the server the source should have a way to select.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1878[PATCH] This patch adds the possibility to put full urls in the list of strea...2019-01-03T16:34:53ZPhilipp Schafft[PATCH] This patch adds the possibility to put full urls in the list of streams fetched from the master server.(reposted from IRC, cato in #icecast)
This patch adds the possibility to put full urls in the list of streams fetched from the master server. When pointing the <master-relay-*> options to a script instead of an icecast this allows to se...(reposted from IRC, cato in #icecast)
This patch adds the possibility to put full urls in the list of streams fetched from the master server. When pointing the <master-relay-*> options to a script instead of an icecast this allows to setup relays of arbitrary streams easily.Icecast 2.4.0Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1877Binding to IPv6 broken on win32 Icecast?2020-02-14T13:01:05ZThomas B. RückerBinding to IPv6 broken on win32 Icecast?This was reported first by mharris on IRC.
He's running WinXP SP3.
I then tried to reproduce it on Win7 64bit with both Icecast 2.3.2 and Icecast 2.3.2-kh33.
On the official build icecast2console.exe will fail to start when given an IPv6...This was reported first by mharris on IRC.
He's running WinXP SP3.
I then tried to reproduce it on Win7 64bit with both Icecast 2.3.2 and Icecast 2.3.2-kh33.
On the official build icecast2console.exe will fail to start when given an IPv6 bind-address (both :: and [::] and also explicit address in both forms). On the KH build it starts but doesn't bind to a port.
I didn't manage to get useful logs out on the official build.
The KH build though complains in the form:
EROR connection/connection_setup_sockets Could not create listener socket on port 8000 bind ::
PS: Unless there is an instant fix, this will miss the window for 2.3.3.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1873[PATCH] icecast does not read arbitrary capitalized headers2018-03-06T12:49:48ZPhilipp Schafft[PATCH] icecast does not read arbitrary capitalized headers(Forwarded from cato on IRC because of #1871)
the YP-Interface does not work according to the http rfc. To be specific icecast does not read arbitrary capitalized headers from the answer as the standard says.
I have written my own impl...(Forwarded from cato on IRC because of #1871)
the YP-Interface does not work according to the http rfc. To be specific icecast does not read arbitrary capitalized headers from the answer as the standard says.
I have written my own implementation of the server-side yp-interface. when I return for example "Ypmessage: 1" instead of "YPMessage: 1" icecast doesn't find the header and the submission to my directory fails
Section 4.2 of RFC 2616 says: "Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.
the error is in http://svn.xiph.org/icecast/trunk/icecast/src/yp.c in handle_returned_header(..) where instead of strncmp a case-insensitive comparison should be madeIcecast 2.4.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1870icecast should send 'expires' in all cases2018-03-06T12:49:48ZThomas B. Rückericecast should send 'expires' in all casescurrently it only sends it in a flash special case.
We should probably do this in all cases unless someone thinks it would break existing clients?currently it only sends it in a flash special case.
We should probably do this in all cases unless someone thinks it would break existing clients?Icecast 2.4.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1867Icecast shared sources in 'httpp', 'net', 'thread' and 'timing' directories n...2018-03-06T12:49:48ZThomas B. RückerIcecast shared sources in 'httpp', 'net', 'thread' and 'timing' directories need license header update (to LGPLv2)As just noticed on #icecast, among others the timing.c and httpp.c files seem to imply GPLv2 while COPYING in that directory says LGPLv2.
Those are also used by e.g. libshout which is LGPLv2...
Suggestion: track down authors, double che...As just noticed on #icecast, among others the timing.c and httpp.c files seem to imply GPLv2 while COPYING in that directory says LGPLv2.
Those are also used by e.g. libshout which is LGPLv2...
Suggestion: track down authors, double check that changing to LGPL is OK.
This would make them compatible with both GPLv2 and LGPLv2 if I understand correctly.
affected files relative to [icecast/trunk/](../tree/master/icecast/trunk/) and who touched them (since tagging GPL):
* [icecast/trunk/timing/timing.c](../tree/master/icecast/trunk/timing/timing.c) giles, karl
* [icecast/trunk/timing/timing.h](../tree/master/icecast/trunk/timing/timing.h) giles, karl, moritz
* [icecast/trunk/net/sock.h](../tree/master/icecast/trunk/net/sock.h) (oddly not sock.c) karl, oddsock, giles, brendan, msmith, jack. plus changes predating https://trac.xiph.org/browser/trunk/net/sock.h?rev=1997
* [icecast/trunk/httpp/httpp.c](../tree/master/icecast/trunk/httpp/httpp.c) msmith, giles, oddsock, karl, ph3-der-loewe
* [icecast/trunk/httpp/httpp.h](../tree/master/icecast/trunk/httpp/httpp.h) msmith, giles, karl, ph3-der-loeweThomas B. RückerThomas B. Rücker