Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2022-02-28T10:58:49Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2408Rename <no-mount>2022-02-28T10:58:49ZPhilipp SchafftRename <no-mount>The config option `<no-mount>` should be renamed to have some better name.
One of the suggestions was `<allow-direct-access>` (which has inverted logic).The config option `<no-mount>` should be renamed to have some better name.
One of the suggestions was `<allow-direct-access>` (which has inverted logic).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/ezstream/-/issues/2271Fatal error when trying to stream with ezstream 1.0.2 in MP3 format2022-10-01T15:48:16ZRoland HermansFatal error when trying to stream with ezstream 1.0.2 in MP3 formatCreating a stream in MP3 format using ezstream 1.0.2 and libshout 2.4.5 fails with following error:
```
$ ezstream -c test_mp3.conf
ezstream[420774]: stream: default: format: MP3: This libshout doesn't support the requested option
```
...Creating a stream in MP3 format using ezstream 1.0.2 and libshout 2.4.5 fails with following error:
```
$ ezstream -c test_mp3.conf
ezstream[420774]: stream: default: format: MP3: This libshout doesn't support the requested option
```
The issue here is that in _stream_cfg_stream an invalid usage value of 0 is passed to shout_set_content_format. This call was introduced in commit 8d882cac. Attached patch [ezstream-1.0.2.patch](/uploads/ba768fa1349c65b60affd496cf4282ed/ezstream-1.0.2.patch) resolves the error. Note that the other calls to shout_set_content_format for different formats may need to be changed too.
Test case configuration file: [test_mp3.conf](/uploads/5bad2b01484c967182bcefb7cda990b5/test_mp3.conf).Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2407status-json.xsl can return invalid JSON at startup2021-04-15T12:13:43ZFunctionstatus-json.xsl can return invalid JSON at startup[I wrote this issue last year](https://github.com/xiph/Icecast-Server/issues/38) but on the GitHub repo. I thought i'd post it here in hopes that someone sees it :)
The page may return this code right after starting Icecast:
```json
{"...[I wrote this issue last year](https://github.com/xiph/Icecast-Server/issues/38) but on the GitHub repo. I thought i'd post it here in hopes that someone sees it :)
The page may return this code right after starting Icecast:
```json
{"icestats":"server_start":"Sat, 03 Oct 2020 15:45:30 +0200","server_start_iso8601":"2020-10-03T15:45:30+0200","dummy":null}}
```
(notice the double closing `}`)
This is invalid JSON, and as i couldn't find a difference between 2.4.4 (which i'm using) and the latest version of the file in master i strongly assume this bug is present in all recent versions. Please correct me if i'm wrong.https://gitlab.xiph.org/xiph/opus/-/issues/2354Question - OPUS downmixing2021-03-25T18:46:19Zdtj20icQuestion - OPUS downmixingHi
I’m using the opus command line tools to process microphone array signals (mostly 8 channel). If I set a bit-rate such that the bit-rate per channel is less than 16kbps then opus begins to downmix. I would like to stop this happeni...Hi
I’m using the opus command line tools to process microphone array signals (mostly 8 channel). If I set a bit-rate such that the bit-rate per channel is less than 16kbps then opus begins to downmix. I would like to stop this happening if that's possible but I can’t find any information on why it’s doing this or how to stop it.
Any thoughts/advice? I figured I could process batches of wavfiles with fewer channels but it’s a bit of an awkward solution.
Thankshttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2331Add an option to disable tools2022-04-10T17:32:00ZFabrice FontaineAdd an option to disable toolsAs I'm unable to fork the project, please find attached a patch that allow the user to disable tools.
[0001-configure.ac-add-an-option-to-disable-tools.patch](/uploads/853966c2c49c76d002f218578e68c1a5/0001-configure.ac-add-an-option-to-...As I'm unable to fork the project, please find attached a patch that allow the user to disable tools.
[0001-configure.ac-add-an-option-to-disable-tools.patch](/uploads/853966c2c49c76d002f218578e68c1a5/0001-configure.ac-add-an-option-to-disable-tools.patch)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2406Icecast SSL stream information2022-04-20T09:19:24ZAlain SeysIcecast SSL stream informationNot realy a issue rather a question we have a icecast server if we listen (vlc)to the http stream we can get the current track information if we listen to the https stream(vlc) we only can hear the stream but no track information is serv...Not realy a issue rather a question we have a icecast server if we listen (vlc)to the http stream we can get the current track information if we listen to the https stream(vlc) we only can hear the stream but no track information is served.
is there a way to also give the track information trough ssl ?
on our website we use a php script to get the trackinformation from a https stream but in vlc we cant get it to work.
please advise mehttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2330URL-escaping ?=& in the mountpoint prevents mountpoints with query strings2022-04-09T19:27:00ZNiko DittmannURL-escaping ?=& in the mountpoint prevents mountpoints with query strings#11b83da8 breaks connecting to mountpoints with a query string.
We are running a libshout compatible streaming server (at least we try ;) ) which uses a query string parameter to set a priority for a source client. This way a newly conn...#11b83da8 breaks connecting to mountpoints with a query string.
We are running a libshout compatible streaming server (at least we try ;) ) which uses a query string parameter to set a priority for a source client. This way a newly connecting source client can auto-kick an existing source client by providing a higher priority. I only now realized that by updating from my old libshout 2.3.1 on debian to 2.4.3 on ubuntu query string get now escaped:
```
SOURCE /m1?prio=3 HTTP/1.0 "ices/0.4 libshout/2.3.1"
SOURCE /m1%3fprio%3d3 HTTP/1.0 "ices/0.4 libshout/2.4.3"
```
I realize that the exact semantics of "mountpoints" aren't formaly specified (or are they?) but this completely broke my expectation of a mount point basically just being the path of a URL.
I opened an [issue on github](https://github.com/xiph/Icecast-libshout/issues/22) before I found the repo here. I'm gonna close over there and refer to this issue here.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2329Unbreak shout.pc (on non-GNU systems)2021-04-16T12:46:56ZMoritz GrimmUnbreak shout.pc (on non-GNU systems)The pkgconfig file shout.pc contains a list of requirements starting with an empty value:
`Requires.private: , ogg, vorbis, theora, speex, libssl`
This is not well-formed and doesn't work with pkgconfig on OpenBSD (for example). Since ...The pkgconfig file shout.pc contains a list of requirements starting with an empty value:
`Requires.private: , ogg, vorbis, theora, speex, libssl`
This is not well-formed and doesn't work with pkgconfig on OpenBSD (for example). Since libogg is a must-have dependency, the simple fix is to just start the list with it.
Patch: [libshout_proper_shout_pc.diff](/uploads/5cf7acd7e02ea62a9712a79375a6b663/libshout_proper_shout_pc.diff)https://gitlab.xiph.org/xiph/rnnoise/-/issues/3rnnoise have any patents inside?2021-03-11T07:14:31ZVasiliy Glazovrnnoise have any patents inside?Hi.
I want to add rnnoise library to Fedora GNU/Linux repository. And I need to know is rnnoise use any patented technology or algorithm?Hi.
I want to add rnnoise library to Fedora GNU/Linux repository. And I need to know is rnnoise use any patented technology or algorithm?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2405Recovering from fallback directs to wrong mount2021-05-08T14:13:53ZLauri HeikkiläRecovering from fallback directs to wrong mountDon't know should one re-open old issue https://gitlab.xiph.org/xiph/icecast-server/-/issues/642 or not, but here's a new one...
One has two mounts (/mount_a and mount_b) with the same fallback mount<br>
-> The sources for both relayed ...Don't know should one re-open old issue https://gitlab.xiph.org/xiph/icecast-server/-/issues/642 or not, but here's a new one...
One has two mounts (/mount_a and mount_b) with the same fallback mount<br>
-> The sources for both relayed mounts (/remote_mount_a and /remote_mount_b) go down<br>
-> All listeners get directed to /backup mount<br>
-> Both relayed sources recover<br>
-> All listeners get directed to single mount, for example /mount_a, even though they were listening /mount_b before
```
<relay>
<server>a.remote.server.com</server>
<mount>/remote_mount_a</mount>
<local-mount>/mount_a</local-mount>
</relay>
<mount type="normal">
<mount-name>/mount_a</mount-name>
<fallback-mount>/backup</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
<relay>
<server>remote.server.com</server>
<mount>/remote_mount_b</mount>
<local-mount>/local_mount_b</local-mount>
</relay>
<mount type="normal">
<mount-name>/mount_b</mount-name>
<fallback-mount>/backup</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
<relay>
<server>b.remote.server.com</server>
<mount>/remote_backup</mount>
<local-mount>/backup</local-mount>
<on-demand>1</on-demand>
</relay>
```Icecast 2.5.0https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2325No connection in nonblocking mode, retry shout_open() fails.2022-04-12T11:02:27ZDaniel SchürmannNo connection in nonblocking mode, retry shout_open() fails.Probably since 2.4.2 and https://gitlab.xiph.org/xiph/icecast-libshout/-/commit/032aa10d93553ede0bbfb1c2f094f9794f12da15
shout_open() returns SHOUTERR_RETRY instead retry until timeout in
https://gitlab.xiph.org/xiph/icecast-libshout/-/...Probably since 2.4.2 and https://gitlab.xiph.org/xiph/icecast-libshout/-/commit/032aa10d93553ede0bbfb1c2f094f9794f12da15
shout_open() returns SHOUTERR_RETRY instead retry until timeout in
https://gitlab.xiph.org/xiph/icecast-libshout/-/blob/master/src/connection.c#L464
Unfortunately it is not possible without closing shout to continue the iteration using shout_open().
It fails with SHOUTERR_CONNECTED
https://gitlab.xiph.org/xiph/icecast-libshout/-/blob/master/src/shout.c#L185
Calling shout_close() does not fix the issue, because it starts the iteration from the beginning.
Is there another public function that can be called?
In my test 70 loops are required to open the connection.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2404Issues in log file dublicate items since start of 20212021-01-04T20:47:54ZHans-Georg AlthoffIssues in log file dublicate items since start of 2021I have figured out, that user access is repeating the same data several times since the beginning of the year.
Usual the lines are ordered by time. Now I can see, that ip adresses are repeating with the same date and time.
This is corr...I have figured out, that user access is repeating the same data several times since the beginning of the year.
Usual the lines are ordered by time. Now I can see, that ip adresses are repeating with the same date and time.
This is corrupting my programm[access.log.old](/uploads/10f05b8ae9d6960d4a921d4654ab6e9c/access.log.old), which I use to analyse the data.https://gitlab.xiph.org/xiph/ezstream/-/issues/2270<sys/random.h> requires <sys/types.h> on OS/X2022-08-20T02:49:16ZMitchell Blank<sys/random.h> requires <sys/types.h> on OS/XOn recent OS/X environments, playlist.c fails to compile because of problems with including `<sys/random.h>` before `<sys/types.h>`:
```
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/i...On recent OS/X environments, playlist.c fails to compile because of problems with including `<sys/random.h>` before `<sys/types.h>`:
```
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/random.h:37:30: error: unknown type name 'size_t'; did you mean 'time_t'?
int getentropy(void* buffer, size_t size);
```
I'm not the first to hit this problem; it looks like MacPorts patched it locally about 9 months ago:
https://raw.githubusercontent.com/macports/macports-ports/fa36881/audio/ezstream/files/sys-types.patch
I can verify that their fix works on my MacOS 11 environment.Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/opus/-/issues/2347cmake - disable ctest for ios and android crosscompiling2022-07-12T14:08:12ZMarcus Asteborgcmake - disable ctest for ios and android crosscompilinghttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2321In non-blocking mode login errors are not correctly reported2020-12-19T13:51:45ZPhilipp SchafftIn non-blocking mode login errors are not correctly reportedWhen libshout is configured in non-blocking mode fatal authentication errors are not forwarded correctly to the application. Instead retry is signalled.When libshout is configured in non-blocking mode fatal authentication errors are not forwarded correctly to the application. Instead retry is signalled.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2402Auth url webhooks not working2020-11-14T16:56:42ZJohn MidsonAuth url webhooks not workingHi guys,
Sorry if I'm missing something obvious, but I really can't make authentication url working.
I have Icecast configs:
```
<mount>
<mount-name>/aac_high</mount-name>
<authentication type="url">
<option...Hi guys,
Sorry if I'm missing something obvious, but I really can't make authentication url working.
I have Icecast configs:
```
<mount>
<mount-name>/aac_high</mount-name>
<authentication type="url">
<option name="listener_add" value="http://localhost:3000/api/v1/listeners/add"/>
<option name="listener_remove" value="http://localhost:3000/api/v1/listeners/remove"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
</authentication>
</mount>
```
By calling `/aac_hight` I got 401 despite server is configured to return correct header:
```
$ curl http://localhost:8000/aac_high
<?xml version="1.0"?>
<report xmlns="http://icecast.org/specs/reportxml-0.0.1" version="0.0.1"><incident><state definition="25387198-0643-4577-9139-7c4f24f59d4a"><text>You need to authenticate</text></state></incident><extension application="http://icecast.org/specs/legacy-icestats"><icestats xmlns="http://icecast.org/specs/legacystats-0.0.1"><modules/></icestats></extension></report>
```
In Icecast's `error.log` I'm getting:
```
[2020-11-05 11:44:02] INFO auth/queue_auth_client auth on /aac_high has 1 pending
[2020-11-05 11:44:02] INFO auth_url/url_add_client client auth (http://localhost:3000/api/v1/listeners/add) failed with ""
[2020-11-05 11:44:02] WARN reportxml/reportxml_database_build_report No matching definition for "25387198-0643-4577-9139-7c4f24f59d4a"
```
So, looks like it is trying to reach `http://localhost:3000/api/v1/listeners/add` but in server logs I don't see any incoming request at all.
Callback on localhost:3000 working fine:
```
$ curl -v -X POST http://localhost:3000/api/v1/listeners/add
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 3000 (#0)
> POST /api/v1/listeners/add HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< icecast-auth-user: 1
< Server: Dominion
< Date: Thu, 05 Nov 2020 12:19:24 GMT
< Connection: keep-alive
< Content-Length: 0
<
* Connection #0 to host localhost left intact
```
Icecast is built from master branch, additional info:
```
$ ./icecast -v
Icecast 2.4.99.2
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
```
Will appreciate any hint what is going wrong. Thanks!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2399Crash Icecast 2.4.4 on CentOS 7.52020-10-19T17:28:24ZMediaKCrash Icecast 2.4.4 on CentOS 7.5Linked from previous report `https://gitlab.xiph.org/xiph/icecast-server/-/issues/2344`
My radio stream service exits on minimal load.
I'm using Icecast 2.4.4
OpenSSL 1.0.2k-fips 26 Jan 2017
On CentOs 7.8
WHM/CPANEL: v90.0.15
`Oct 18 ...Linked from previous report `https://gitlab.xiph.org/xiph/icecast-server/-/issues/2344`
My radio stream service exits on minimal load.
I'm using Icecast 2.4.4
OpenSSL 1.0.2k-fips 26 Jan 2017
On CentOs 7.8
WHM/CPANEL: v90.0.15
`Oct 18 02:18:33 server1 kernel: traps: icecast[16512] general protection ip:7f2327a88c09 sp:7ffdab32ab80 error:0 in libssl.so.1.0.2k[7f2327a5c000+67000]
`
With added errors
`Oct 18 02:18:33 server1 systemd: icecast.service: main process exited, code=killed, status=11/SEGV
Oct 18 02:18:33 server1 systemd: Unit icecast.service entered failed state.
Oct 18 02:18:33 server1 systemd: icecast.service failed.`
How can this be resolved?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2398Handling of GET request on admin/ should be updated2020-10-15T15:24:33ZPhilipp SchafftHandling of GET request on admin/ should be updatedCurrently GET request are handled alike POST request. This should be changed to the following:
In operation mode `legacy`: \
Keep as is.
In operation mode `normal`: \
Write a warning about such clients.
In operation mode `strict`: \
R...Currently GET request are handled alike POST request. This should be changed to the following:
In operation mode `legacy`: \
Keep as is.
In operation mode `normal`: \
Write a warning about such clients.
In operation mode `strict`: \
Reject the request.Philipp SchafftPhilipp Schaffthttps://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/opus/-/issues/2342cmake - fix lrint detection on Linux ARM2022-07-12T14:05:12ZMarcus Asteborgcmake - fix lrint detection on Linux ARMlrint detection needs -m flaglrint detection needs -m flag