Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2020-10-15T13:51:17Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/738Errorcode when client wants to connect to "full" mountpoint should be changed2020-10-15T13:51:17ZrobeErrorcode when client wants to connect to "full" mountpoint should be changedHi,
the errorcode that clients receive when they want to connect to a mountpoint which has reached its maxlisteners limit should be changed from the current "404 File Not Found" to something more meaningful, since this is the same error...Hi,
the errorcode that clients receive when they want to connect to a mountpoint which has reached its maxlisteners limit should be changed from the current "404 File Not Found" to something more meaningful, since this is the same errorcode that gets returned when the requested mountpoint doesn't exist.
A possible solution to this would be returning 403 with a customized reason phrase like "Mountpoint full" (or similar) in the header (since this is the only thing (if any) that gets forwarded to the user with most clients). The HTTP 1.1 RFC (#2616) allows this:
6.1.1:
[..]
The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only
recommendations -- they MAY be replaced by local equivalents without
affecting the protocol.
[..]Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2380Invalid JSON structure when title is empty2020-10-11T11:37:16ZEdwin HermannInvalid JSON structure when title is emptyBelow is a snippet of the JSON structure returned from /status-json.xsl when the song title is empty:
```
"stream_start":"Mon, 28 Oct 2019 10:49:00 +1300",
"stream_start_iso8601":"2019-10-28T10:49:00+1300",
...Below is a snippet of the JSON structure returned from /status-json.xsl when the song title is empty:
```
"stream_start":"Mon, 28 Oct 2019 10:49:00 +1300",
"stream_start_iso8601":"2019-10-28T10:49:00+1300",
"title": - ,
"dummy":null
}
```
The problem item here is "title". The resulting JSON string does not parse correctly because of the hyphen. To fix the bug, the hyphen should be enclosed in double-quotes.
The server whence this came is not mine so I am not able to determine why it is that the Icecast server is returning an unquoted hyphen. The server concerned has been that way for several days; the URL is http://219.89.83.33:8000/status-json.xslhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2112Locks on avl client_trees needed?2020-10-11T11:18:30ZMarvin ScholzLocks on avl client_trees needed?>do we need to use locks on the avl client_trees in source.c and fserv.c?
Found in TODO, still relevant?>do we need to use locks on the avl client_trees in source.c and fserv.c?
Found in TODO, still relevant?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2363Use of `<shoutcast-compat>` results in unexpected behaviour2020-10-11T09:01:32ZPhilipp SchafftUse of `<shoutcast-compat>` results in unexpected behaviourWhen setting `<shoutcast-mount>` within `<listen-socket>` two sockets will be created:
* A normal one with the shoutcast mount set
* A second one at (`port` + 1) with shoutcast mount set as ICY source port (`<shoutcast-compat>` set).
Ho...When setting `<shoutcast-mount>` within `<listen-socket>` two sockets will be created:
* A normal one with the shoutcast mount set
* A second one at (`port` + 1) with shoutcast mount set as ICY source port (`<shoutcast-compat>` set).
However you can set `<shoutcast-compat>` manually. In this case also two ports are opened at `port` and `port` + 1 with both being identical in configuration.
The code uses the following condition to check if the extra socket must be created:
```c
if (listener->shoutcast_mount) {
```
However I think it should be:
```c
if (listener->shoutcast_mount && !listener->shoutcast_compat) {
```
This will prevent the listen socket on `port` + 1 to be created.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2261Check if bitrate is missing on admin stats page2020-10-10T11:46:49ZMarvin ScholzCheck if bitrate is missing on admin stats pageAs asked by Jack Elliott on the mailing list:
> A RFE: would it be possible for the current stream bitrates to be
> displayed on stats.xsl ?As asked by Jack Elliott on the mailing list:
> A RFE: would it be possible for the current stream bitrates to be
> displayed on stats.xsl ?Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2174icestats.source in /status-json.xsl is not always an array2020-10-10T11:40:10ZDavid Thompsonicestats.source in /status-json.xsl is not always an arrayWhen there is only one mount, icestats.source is an object. When there is more than one mount, icestats.source is an array. This is quite surprising, and it means that client code has to be careful to test for this case and handle it a...When there is only one mount, icestats.source is an object. When there is more than one mount, icestats.source is an array. This is quite surprising, and it means that client code has to be careful to test for this case and handle it appropriately.
icestats.source should always be an array of objects describing the mounts, even if there is only one of them.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2372Icecast 'locks up' on SIGHUP if there are duplicate listener-sockets in the c...2020-10-10T10:13:32ZThomas B. RückerIcecast 'locks up' on SIGHUP if there are duplicate listener-sockets in the configAs reported by 'szett' on IRC.
Excerp of the offending config file:
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</li...As reported by 'szett' on IRC.
Excerp of the offending config file:
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</listen-socket>
<!-- SOCKET FOR SOURCES -->
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</listen-socket>Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2395Missing files in share/admin after make install2020-10-09T16:38:28ZGilouMissing files in share/admin after make installA few of the newer xsl files for admin are missing after make install:
```
~/icecast-server$ diff -r admin/ /usr/local/share/icecast/admin/ | grep -v Makefile
Only in admin/: dashboard.xsl
Only in admin/: fallbacks.xsl
Only in admin/incl...A few of the newer xsl files for admin are missing after make install:
```
~/icecast-server$ diff -r admin/ /usr/local/share/icecast/admin/ | grep -v Makefile
Only in admin/: dashboard.xsl
Only in admin/: fallbacks.xsl
Only in admin/includes: player.xsl
Only in admin/includes: playlist.xsl
Only in admin/: showlog.xsl
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2396Unifiy <xsl:output>-settings for web/ and admin/2020-10-09T16:38:28ZPhilipp SchafftUnifiy <xsl:output>-settings for web/ and admin/`<xsl:output>`-settings must match web/ and admin/ as they share some templates.`<xsl:output>`-settings must match web/ and admin/ as they share some templates.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2394Include libshout release 2.4.4 on website2020-10-02T20:20:37ZPhilipp SchafftInclude libshout release 2.4.4 on websiteThe following libshout release should distributed on the mirrors and then included in the website:
```
ddc44d4db0193471b1a61d41e8ec975a021da4f5af657716ecbb1eaf95231e03ac44036148f0d5bd897ba5c03f075fd67017fecfccebb4f11be56375c0e5c088 lib...The following libshout release should distributed on the mirrors and then included in the website:
```
ddc44d4db0193471b1a61d41e8ec975a021da4f5af657716ecbb1eaf95231e03ac44036148f0d5bd897ba5c03f075fd67017fecfccebb4f11be56375c0e5c088 libshout-2.4.4.tar.gz
7273d5e8da3ad10e6fc754663df5b56e8058a41f libshout-2.4.4.tar.gz
```Ralph GilesRalph Gileshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2382Streaming over SSL disconnects2020-10-02T13:45:10ZcyberStreaming over SSL disconnectsHi,
ERROR:
Feb 25 13:27:39 hostname kernel: icecast[550]: segfault at 7f2b7fe74000 ip 00007f2b7faa3a56 sp 00007ffef066b1a0 error 4 in libcrypto.so.1.0.1e[7f2b7fa2d000+1ba000]
Feb 25 17:22:07 hostname kernel: icecast[21702]: segfault at ...Hi,
ERROR:
Feb 25 13:27:39 hostname kernel: icecast[550]: segfault at 7f2b7fe74000 ip 00007f2b7faa3a56 sp 00007ffef066b1a0 error 4 in libcrypto.so.1.0.1e[7f2b7fa2d000+1ba000]
Feb 25 17:22:07 hostname kernel: icecast[21702]: segfault at 7f31c0de6000 ip 00007f31c0a15a56 sp 00007fff82c831f0 error 4 in libcrypto.so.1.0.1e[7f31c099f000+1ba000]
We have a station configured with icecast with SSL and has random disconnections.
Versions:
/usr/local/bin/icecast -v
Icecast 2.4.4
OpenSSL 1.0.1e-fips 11 Feb 2013
CentOS release 6.10
Centova Cast 3.2.10.20170725.stable-519r4029
Does anyone know if there is any way to solve this?
All I have found is this link but there is no solution in this regard:
https://gitlab.xiph.org/xiph/icecast-server/issues/2283
Kind regards,https://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/2385[PATCH] StreamUrl metadata not included in stream2020-10-02T13:04:13ZJoakim Lagerqvist[PATCH] StreamUrl metadata not included in streamHello,
When setting the metadata over admin interface, the url parameter is ignored. For example, if the metadata is set with the following call:
`http://192.168.1.10:8000/admin/metadata?mount=/mystream&mode=updinfo&song=ACDC+Back+In+...Hello,
When setting the metadata over admin interface, the url parameter is ignored. For example, if the metadata is set with the following call:
`http://192.168.1.10:8000/admin/metadata?mount=/mystream&mode=updinfo&song=ACDC+Back+In+Black&url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FAC%2FDC`
I would expect to see the following in the stream:
`StreamTitle='ACDC Back In Black';StreamUrl='https://en.wikipedia.org/wiki/AC/DC';`
However, only the StreamTitle gets propagated. Looking into the code, most of the support is there, only missing the functionality to save the 'url' parameter in the admin section. Attached is a tested patch.
Cheers,
Joakim @ Radio Sweden/Sveriges Radio
[streamurl.patch](/uploads/8a037825e4a7ee0f2cacc3193b58fdeb/streamurl.patch)
Edit: realised there were some tabs instead of spaces in the patch.Philipp SchafftPhilipp Schaffthttps://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/807Viewing the last X number of lines from logfile in Icecast Web Admin2020-10-02T11:46:58Zdj_transidViewing the last X number of lines from logfile in Icecast Web AdminIn the Icecast web admin is it possible to have it show say X number of lines from the errors.log just so that the admin doesnt need to have shell access to know what is going on the background, shoutcast has the same thing where it tail...In the Icecast web admin is it possible to have it show say X number of lines from the errors.log just so that the admin doesnt need to have shell access to know what is going on the background, shoutcast has the same thing where it tails the log file. just a thought.
Thanks,
~BrianIcecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2386Unable to disable SSL build in libshout-2.4.32020-10-01T18:33:57ZNight GryphonUnable to disable SSL build in libshout-2.4.3./configure --without-openssl
still do ssl tests and add
#define HAVE_OPENSSL 1
to config.h which cause tls.c and other unwanted ssl stuff to build in to library./configure --without-openssl
still do ssl tests and add
#define HAVE_OPENSSL 1
to config.h which cause tls.c and other unwanted ssl stuff to build in to libraryhttps://gitlab.xiph.org/xiph/opus/-/issues/2339libopus 1.2.1 - Windows - Integer division by zero2020-09-01T20:43:17ZAlexander Matveevlibopus 1.2.1 - Windows - Integer division by zeroHi everyone,
Our crash detection system registered Unhandled exceptions:
silk_Decode + 2485 (edited) \silk\dec_API.c(317)
opus_decode_frame + 971 (edited) \src\opus_decoder.c(381)
opus_decode_native + 763 (edited) \src\opus_decoder.c(6...Hi everyone,
Our crash detection system registered Unhandled exceptions:
silk_Decode + 2485 (edited) \silk\dec_API.c(317)
opus_decode_frame + 971 (edited) \src\opus_decoder.c(381)
opus_decode_native + 763 (edited) \src\opus_decoder.c(693)
opus_decode + 218 (edited) \src\opus_decoder.c(782)
Unhandled exception at (edited): Integer division by zero.
/* Number of output samples */
*nSamplesOut = silk_DIV32( nSamplesOutDec * decControl->API_sampleRate, silk_SMULBB( channel_state[ 0 ].fs_kHz, 1000 ) );
We do not know how we can reproduce this issue. We started seeing this issue a year ago and we still receive these crash reports.
Please investigate the issue or suggest us what we should debug.
Thank you for helping!
Alexhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2390status-json with fallback-mount2020-08-31T15:48:47ZIgor dWstatus-json with fallback-mountI have icecast 2.4.4 with win2016 server. I'm using a fallback-mount. When the fallback mount is active my player gets the metadata from this mount and works perfect. When the 'main' mount gets active, icecast switches perfect, and in my...I have icecast 2.4.4 with win2016 server. I'm using a fallback-mount. When the fallback mount is active my player gets the metadata from this mount and works perfect. When the 'main' mount gets active, icecast switches perfect, and in my status-json my 'main' mount is first presented so my player pickes te metadata correct. When the 'main' mount is lost and icecast switches to the fallback mount things go wrong. The music switches but in status-json the metadata from the 'main' mount is not dropped/removed so my player is looking to empty strings and is not presenting artist and song information. The 'main' mount is also not dropped in the icecast server status (but empty, containing no data). When i at this point also disconnect the fallback, both are removed from status-json. Is this a setting i have to change or a bug?
[Icecast_xml_settings.txt](/uploads/be6d02c1146dea8396b28c984b0178fa/Icecast_xml_settings.txt)https://gitlab.xiph.org/xiph/speexdsp/-/issues/3Ubuntu Aaarch64 18.04 ./configure error2020-08-11T02:16:11ZStuartIanNaylorUbuntu Aaarch64 18.04 ./configure error
checking for cos in -lm... yes
./configure: line 13500: syntax error near unexpected token `FFT,'
./configure: line 13500: ` PKG_CHECK_MODULES(FFT, fftw3f)'
Tried installing all the fftw packages -dev also
Going to switch for debian ...
checking for cos in -lm... yes
./configure: line 13500: syntax error near unexpected token `FFT,'
./configure: line 13500: ` PKG_CHECK_MODULES(FFT, fftw3f)'
Tried installing all the fftw packages -dev also
Going to switch for debian and give it a go as you can tell apart from simple compiling I am lost.
Posted here also seems both Ubuntu & Debian tried 18.04 & 20.04 64 bit
https://github.com/xiph/speexdsp/issues/31#issuecomment-633379070https://gitlab.xiph.org/xiph/ogg/-/issues/2300Check for overflow on growing buffer2020-08-09T22:44:22ZClément BœschCheck for overflow on growing bufferHi,
I came across this code while debugging an issue in libshout (https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318), and it looked pretty unsafe to me: [0001-framing-check-for-overflow-on-growing-buffer.patch](/uploads/376286...Hi,
I came across this code while debugging an issue in libshout (https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318), and it looked pretty unsafe to me: [0001-framing-check-for-overflow-on-growing-buffer.patch](/uploads/376286b5321247d4934f85e924bdb2be/0001-framing-check-for-overflow-on-growing-buffer.patch).
One could check that the `oy->storage<0` and similar checks are enough, but I still believe it's safer not to assign the invalid value in the first place.