Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2019-07-04T20:20:25Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2323m3u/xspf/vclt files do not support SSL2019-07-04T20:20:25ZGitlab Botm3u/xspf/vclt files do not support SSLRegardless of the settings within the config file, the url created in the m3u/xspf/vclt files is still in HTTP.
It looks to be due to the following lines in /src/fserve.c (lines 476 till 493) where the http is hardcoded:
```
if ...Regardless of the settings within the config file, the url created in the m3u/xspf/vclt files is still in HTTP.
It looks to be due to the following lines in /src/fserve.c (lines 476 till 493) where the http is hardcoded:
```
if (host == NULL)
{
config = config_get_config();
snprintf (httpclient->refbuf->data + ret, BUFSIZE - ret,
"http://%s:%d%s\r\n",
config->hostname, config->port,
sourceuri
);
config_release_config();
}
else
{
snprintf (httpclient->refbuf->data + ret, BUFSIZE - ret,
"http://%s%s\r\n",
host,
sourceuri
);
}
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2326Icecast- 2.4.3 Do not publish directory yp2017-10-05T10:40:40ZGitlab BotIcecast- 2.4.3 Do not publish directory ypI run icecast 2.4.3 with correct configuration and it does not publish in YP directory.
With the same configuration, version 2.4.1 publishes correctly in directory YPI run icecast 2.4.3 with correct configuration and it does not publish in YP directory.
With the same configuration, version 2.4.1 publishes correctly in directory YPThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2426Icecast fluttery audio2022-03-21T09:37:02ZcrunchysteveIcecast fluttery audiohttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2306Problem installing icecast repository2017-10-05T10:40:40ZradioonlinehdProblem installing icecast repositoryHello
I already tried to install the icecast repository in many ways, in my dedicated server CENTOS 6.8
But I could not do it.
You can see the error you're showing me.
I do not know if I'm doing it wrong, or there is a problem really.
I ...Hello
I already tried to install the icecast repository in many ways, in my dedicated server CENTOS 6.8
But I could not do it.
You can see the error you're showing me.
I do not know if I'm doing it wrong, or there is a problem really.
I ask you to help me as soon as possible, I am interested in updating Icecast 2.3.3-kh11 to Icecast 2.4.0-kh3
```
root@icecastsingle [~]# rpm --import http://download.opensuse.org/repositories/multimedia:/xiph/CentOS_6
error: http://download.opensuse.org/repositories/multimedia:/xiph/CentOS_6: key 1 not an armored public key.
```
Thank you very much.Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2322gzip http compression for server pages.2019-01-09T11:59:13ZRoger Hågensengzip http compression for server pages.With Icecast 2.4.x there is no gzip compression used for served pages.
While most served pages are not that large, gzip may be the difference between a page being served in one TCP packet vs multiple.
And then there are monstrosity lik...With Icecast 2.4.x there is no gzip compression used for served pages.
While most served pages are not that large, gzip may be the difference between a page being served in one TCP packet vs multiple.
And then there are monstrosity like this http://relay.sonixcast.com/ that would clearly benefit from gzip.
gzip could even be applied to xml stats pages as PHP and other serverside scripting languages also support gzip.
While technical it may be possible to apply gzip to the actual stream I would not advise that, the benefit would be minimal in most cases and the compatibility issues with older players could be high (they may support gzip pages but not gzip audiostreams for example).
gzip should probably be enabled by default so that the "optimal" settings are enabled "out of the box".
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2305Icecast stream doesn't play properly using PotPlayer(64 bit, v 1.6.638912017-10-05T10:40:40ZkontrstIcecast stream doesn't play properly using PotPlayer(64 bit, v 1.6.63891When I play Otto's Baroque Music Radio, http://185.33.21.112:11037 no problem.
But get distortion WNYC AM (Icecast) http://am820.wnyc.org/wnycam.
When I play Otto's Baroque Music Radio, http://185.33.21.112:11037 no problem.
But get distortion WNYC AM (Icecast) http://am820.wnyc.org/wnycam.
Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2318icecast fails to build against openssl-1.1 that lacks deprecated features2019-04-24T17:23:49ZGitlab Boticecast fails to build against openssl-1.1 that lacks deprecated featuresicecast-2.5_beta1 (and 2.4.3 as well) fails to build against openssl-1.1 that lacks deprecated features. This is the case when openssl-1.1 was built with either "--api=1.1.0" or "no-deprecated" option. The build issues look like this:
`...icecast-2.5_beta1 (and 2.4.3 as well) fails to build against openssl-1.1 that lacks deprecated features. This is the case when openssl-1.1 was built with either "--api=1.1.0" or "no-deprecated" option. The build issues look like this:
```
i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I./common/ -Wall -ffast-math -fsigned-char -I/usr/include/libxml2 -I/usr/include -pthread -march=native -O2 -pipe -c -o connection.o connection.c
connection.c: In function ‘get_ssl_certificate’:
connection.c:195:5: warning: implicit declaration of function ‘SSL_load_error_strings’ [-Wimplicit-function-declaration]
SSL_load_error_strings(); /* readable error messages */
^
connection.c:196:5: warning: implicit declaration of function ‘SSL_library_init’ [-Wimplicit-function-declaration]
SSL_library_init(); /* initialize library */
^
connection.c:198:12: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
method = SSLv23_server_method();
^
```
And later in the linking part:
```
libtool: link: i686-pc-linux-gnu-gcc -pthread -march=native -O2 -pipe -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -o icecast cfgfile.o main.o logging.o sighandler.o connection.o global.o util.o slave.o source.o stats.o refbuf.o client.o xslt.o fserve.o admin.o md5.o format.o format_ogg.o format_mp3.o format_midi.o format_flac.o format_ebml.o format_kate.o format_skeleton.o format_opus.o event.o event_log.o event_exec.o acl.o auth.o auth_htpasswd.o auth_anonymous.o auth_static.o format_vorbis.o format_theora.o format_speex.o auth_url.o event_url.o yp.o -L/usr/lib -Wl,--as-needed common/net/.libs/libicenet.a common/thread/.libs/libicethread.a common/httpp/.libs/libicehttpp.a common/log/.libs/libicelog.a common/avl/.libs/libiceavl.a common/timing/.libs/libicetiming.a -lcurl -lnghttp2 -lidn2 -lssl -lcrypto -lspeex -ltheora -lvorbis -logg -lxslt -lxml2 -lz -ldl -lm -pthread
connection.o: In function `connection_accept_loop':
connection.c:(.text+0x736): undefined reference to `SSL_load_error_strings'
connection.c:(.text+0x73b): undefined reference to `SSL_library_init'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:512: icecast] Error 1
```
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2299Deadlock in SIGHUP signal handler2017-10-05T10:40:40ZVincent HuismanDeadlock in SIGHUP signal handlerI noticed that sometimes during reloading of the configuration, icecast would stop responding. This seems to be caused by mutex code in the signal handlers. It is possible to end up in a state where the mutex has been acquired by `global...I noticed that sometimes during reloading of the configuration, icecast would stop responding. This seems to be caused by mutex code in the signal handlers. It is possible to end up in a state where the mutex has been acquired by `global_lock()` (i.e. due to an incoming connection) but not yet released before the signal handler is called. Then, `global_lock()` is called again in the signal handler, but since it is already locked by the same thread, that call will block forever and the server stops handling new incoming requests.
### Affected versions:
* icecast2=2.4.0-1.1+deb8u1 (the current version in Debian Jessie)
* icecast2=2.4.2-1~bpo8+1 icecast2 binary only
I have encountered and reproduced this problem on icecast2=2.4.0-1.1+deb8u1. In trying to isolate the problem, I accidentally used the sources for icecast2=2.4.2-1~bpo8+1 and only copied the icecast2 binary over the already installed binary version, but that does not really change the outcome.
### Steps to reproduce:
* Simulate a lot of concurrent connection attempts
* While doing this, `kill -HUP icecast2`
### Expected result:
* Server handles those requests, reloads the config a couple of times
### Actual result:
* Server stops handling requests suddenly
```
# ab -t 20 -c 50 http://localhost:8000/ & for i in `seq 1 20`; do sleep 1; kill -HUP $(pidof icecast2); done[1] 2409
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
apr_socket_recv: Connection reset by peer (104)
Total of 15175 requests completed
[1]+ Exit 104 ab -t 20 -c 50 http://localhost:8000/
#
```
### Probable cause:
I added some extra logging to `_sig_hup()` and `global_lock()`, and an `usleep(100000)` to the latter after acquiring the mutex. In this setup, a simple call `curl http://localhost:8000/ & kill -HUP $(pidof icecast2)` is enough to trigger this problem every time, and it clearly shows the mutex being acquired due to the incoming connection, and an attempt to lock it again in the signal handler before it being released. The daemon then stops responding.
The underlying cause seems to be the attempt to acquire the global lock in the signal handling code. The same problem may occur in other scenarios as well. It looks to me that only `_sig_hup()` can trigger this bug.
### Proposed solution:
I'm not too much into the icecast code so I'm not really aware of any best/common practices yet, but I think an approach where the signal sets a global `global.reload_config = true` which is then handled in the main event loop (outside the signal handler) would do the trick, much the same way as `_sig_die()` works.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2316MP3 files sent by Icecast do not play on Chrome2018-08-27T12:34:43ZLaurensGMP3 files sent by Icecast do not play on ChromeI have a webpage with Jplayer to play .mp3 files from an Icecast server. Up to and including icecast version 2.4.0 this works on all browsers (Firefox, IE, Edge, Chrome on Windows; Firefox, Puffin, Chrome on Android). When using icecast ...I have a webpage with Jplayer to play .mp3 files from an Icecast server. Up to and including icecast version 2.4.0 this works on all browsers (Firefox, IE, Edge, Chrome on Windows; Firefox, Puffin, Chrome on Android). When using icecast versions 2.4.2 or 2.4.3 it works on all browsers except Chrome.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2313Add a history url2019-11-27T11:34:37ZRoger HågensenAdd a history urlA example url would be: http://127.0.0.1:8000/playing.json?mount=/live
The following is the minimum amount of information that a Webplayer or Website/Forum plugin/Blob plugin would need:
```
{
"server_name":"Testing Stuff",
"server_des...A example url would be: http://127.0.0.1:8000/playing.json?mount=/live
The following is the minimum amount of information that a Webplayer or Website/Forum plugin/Blob plugin would need:
```
{
"server_name":"Testing Stuff",
"server_description":"Blah blah blah",
"history":
[
{"date":"2017-03-03T10:52:10Z","artist":"Some artist","title":"Some song (this is the current one)"},
{"date":"2017-03-03T10:48:10Z","artist":"Some other artist 2","title":"Some Song 2"},
{"date":"2017-03-03T10:44:10Z","artist":"Artist 3","title":"Song 3"},
{"date":"2017-03-03T10:40:10Z","artist":"Artist 4","title":"Song 4"},
{"date":"2017-03-03T10:36:10Z","artist":"Artist 5","title":"Song 5"},
{"date":"2017-03-03T10:32:10Z","artist":"Artist 6","title":"Song 6"},
{"date":"2017-03-03T10:28:10Z","artist":"Artist 7","title":"Song 7"},
{"date":"2017-03-03T10:24:10Z","artist":"Artist 8","title":"Song 8"},
{"date":"2017-03-03T10:20:10Z","artist":"Artist 9","title":"Song 9"},
{"date":"2017-03-03T10:16:10Z","artist":"Artist 10","title":"Song 10"}
]
}
```
The server_name and server_description is included since those could change between DJs (and are nice to display in the webplayer to the listener).
The date for each song (ISO 8601 standard) is somewhat useful, not only can a webplayer show the start time for each song to the listener but (with the exception of the current song) it can calculate and show the duration of songs which a listener or visitor may find interesting.
JSON is convenient as it would need next to no processing by a server script before being passed to a Webplayer or used on a webpage via XHR.
Now as Icecast uses XML internally (mentioned on the icecast-dev mailing list recently) a alternative could be:
A example url would be: http://127.0.0.1:8000/playing.xml?mount=/live
And the following content:
```
<?xml version="1.0" encoding="UTF-8"?>
<source mount="/live">
<server_name>Testing Stuff</server_name>
<server_description>Blah blah blah</server_description>
<history>
<track>
<date>2017-03-03T10:52:10Z</date>
<artist>Some artist</artist>
<title>Some song (this is the current one)</title>
</track>
<track>
<date>2017-03-03T10:48:10Z</date>
<artist>Some other artist 2</artist>
<title>Some Song 2</title>
</track>
<track>
<date>2017-03-03T10:44:10Z</date>
<artist>Artist 3</artist>
<title>Song 3</title>
</track>
<track>
<date>2017-03-03T10:40:10Z</date>
<artist>Artist 4</artist>
<title>Song 4</title>
</track>
<track>
<date>2017-03-03T10:36:10Z</date>
<artist>Artist 5</artist>
<title>Song 5</title>
</track>
<track>
<date>2017-03-03T10:32:10Z</date>
<artist>Artist 6</artist>
<title>Song 6</title>
</track>
<track>
<date>2017-03-03T10:28:10Z</date>
<artist>Artist 7</artist>
<title>Song 7</title>
</track>
<track>
<date>2017-03-03T10:24:10Z</date>
<artist>Artist 8</artist>
<title>Song 8</title>
</track>
<track>
<date>2017-03-03T10:20:10Z</date>
<artist>Artist 9</artist>
<title>Song 9</title>
</track>
<track>
<date>2017-03-03T10:16:10Z</date>
<artist>Artist 10</artist>
<title>Song 10</title>
</track>
</history>
</source>
```
The XML is not quite as elegant as the JSON but it gets the job done and I'd rather see it as XML than never as JSON.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2293High CPU usage on macOS Sierra2017-10-05T10:40:40ZSanderHigh CPU usage on macOS SierraI am experiencing high CPU (95%) on macOS when connecting to a local Icecast server. The high CPU starts when a source connects, and remains even afer sources are no longer connected, until I restart the server.
Versions tested:
1. hom...I am experiencing high CPU (95%) on macOS when connecting to a local Icecast server. The high CPU starts when a source connects, and remains even afer sources are no longer connected, until I restart the server.
Versions tested:
1. homebrew 2.4.2 with my custom config,
2. compiled from source 2.4.3 with default config.
When running within a virtualbox Ubuntu server instance, Icecast is behaving nicely.
I've ran a Instruments time + counter trace, data is available from https://dl.dropboxusercontent.com/u/70903/Icecast%20Instruments.zip and attached to this ticket.
It seems to show that 97% of the time fserve_client_waiting is doing a poll, not sure if this is normal I'm not experienced with this subject. 1 every millisecond if I'm reading the counter correctly.
[12:28] <+tbr> I guess this is something we should definitely look into.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2311Parametrize TLS/SSL Protocol in Icecast config file2021-09-28T12:50:45ZGitlab BotParametrize TLS/SSL Protocol in Icecast config fileWe currently have the option of enabling SSL, defining ciphers and certificate files. Would you please add the option to define the protocol.
Example could be:
```
<SSL_Protocol>SSL_OP_NO_TLSv1|SSL_OP_NO_TLSv1_1|SSL_OP_NO_SSLv2|SSL_OP_...We currently have the option of enabling SSL, defining ciphers and certificate files. Would you please add the option to define the protocol.
Example could be:
```
<SSL_Protocol>SSL_OP_NO_TLSv1|SSL_OP_NO_TLSv1_1|SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3</SSL_Protocol>
```
The current ability to define ciphers is great but some ciphers are backwards compatible. From a security standpoint, it would be great to be able to control the protocols available.
Is there a workaround for me without needing to recompile as I've installed from Xiph repository.
Thank you so much for your time!Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2277Have status.xsl show the html5 in-line player also for audio/mpeg2017-10-05T10:40:40ZDaniel LublinHave status.xsl show the html5 in-line player also for audio/mpegThis is commonly supported now days, any reason not to show it?
This is commonly supported now days, any reason not to show it?
Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2310re-license to "GPL-2. with OpenSSL exception"2018-06-16T20:52:48ZJamiere-license to "GPL-2. with OpenSSL exception"The debian version of icecast2 doesn't ship with openssl, which means we can't embed streams in https pages without a mixed-content warning.
The debian maintainers report that [it is due to a openssl licensing conflict](https://bugs.deb...The debian version of icecast2 doesn't ship with openssl, which means we can't embed streams in https pages without a mixed-content warning.
The debian maintainers report that [it is due to a openssl licensing conflict](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744815#15) that could be resolved if icecast2 could be re-licensed to include an exception for openssl (among other options).
Is that option viable? Other options?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2273Link error when compiling with cURL2017-10-05T10:40:40ZMarvin ScholzLink error when compiling with cURLIf cURL is detected and not explicitly disabled using `--without-curl` I get a linker error:
```
Undefined symbols for architecture x86_64:
"_icecast_curl_free", referenced from:
_auth_url_clear in auth_url.o
_event_get_u...If cURL is detected and not explicitly disabled using `--without-curl` I get a linker error:
```
Undefined symbols for architecture x86_64:
"_icecast_curl_free", referenced from:
_auth_url_clear in auth_url.o
_event_get_url in event_url.o
_event_url_free in event_url.o
_destroy_yp_server in yp.o
"_icecast_curl_initialize", referenced from:
_initialize_subsystems in main.o
_main in main.o
"_icecast_curl_new", referenced from:
_auth_get_url_auth in auth_url.o
_event_get_url in event_url.o
_yp_recheck_config in yp.o
"_icecast_curl_shutdown", referenced from:
_shutdown_subsystems in main.o
ld: symbol(s) not found for architecture x86_64
```Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2309Can't connect to Icecast server from multiple tabs in Firefox2019-05-13T11:49:02ZugultopuCan't connect to Icecast server from multiple tabs in Firefox
## Steps to Reproduce
1. Open Firefox 50.1.0.
2. Connect to an Icecast mount point. The stream will start.
3. Open a new tab and try to connect to the same mount point. The connection won't be established.
4. Open a Private Window and t...
## Steps to Reproduce
1. Open Firefox 50.1.0.
2. Connect to an Icecast mount point. The stream will start.
3. Open a new tab and try to connect to the same mount point. The connection won't be established.
4. Open a Private Window and try to connect to the same mount point. The stream will start.
5. Open another tab in the Private Window and try to connect to the same mount point. The connection won't be established.
## Actual Results
Can't establish connection to an Icecast server from multiple tabs in Firefox.
## Expected Results
Establish connection to an Icecast server from multiple tabs in Firefox.
## Notes
1. The issue does not occur on Chrome. It is possible to connect to a mount point from as many tabs as you like.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2272Rename <mp3-metadata-interval> for clarity2017-10-05T10:40:40ZMarvin ScholzRename <mp3-metadata-interval> for clarityCurrently we have a mount specific config parameter called `mp3-metadata-interval`, which sets the metadata interval for ICY metadata, used for MP3 or AAC (and maybe some other formats). Therefore the name is misleading, especially for u...Currently we have a mount specific config parameter called `mp3-metadata-interval`, which sets the metadata interval for ICY metadata, used for MP3 or AAC (and maybe some other formats). Therefore the name is misleading, especially for users that stream AAC.
I would like to propose renaming it to `icy-metadata-interval` for clarity that this affects ICY and not just mp3.Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2302Password extends into headers with BUTT shoutcast compatible source2020-02-14T13:26:12ZGary TunstallPassword extends into headers with BUTT shoutcast compatible sourceHi, I've found a bug in 2.4.3 (which if I understand correctly is the same as 2.4.2 for Linux).
Its a fairly minor one and is in part caused by the Source.
If you use BUTT (https://sourceforge.net/projects/butt/) to broadcast and setup a...Hi, I've found a bug in 2.4.3 (which if I understand correctly is the same as 2.4.2 for Linux).
Its a fairly minor one and is in part caused by the Source.
If you use BUTT (https://sourceforge.net/projects/butt/) to broadcast and setup an Icecast connection it works find. However if you set it up as a shoutcast connection and send to a shoutcast compatible port on icecast it fails.
Now the obvious question is why we'd use the "old" way of doing things. The answer is we are moving from shoutcast to icecast and a lot of our broadcasters still have the shoutcast settings and I'll like it to "just work" for them.
The problem is BUTT mixes its line endings, after the password there is just a /n but in the header lines it uses /r/n
In _handle_shoutcast_compatible in connection.c there is some code
```
/* Get rid of trailing \r\n or \n after password */
ptr = strstr (client->refbuf->data, "\r\r\n");
if (ptr)
headers = ptr+3;
else
{
ptr = strstr (client->refbuf->data, "\r\n");
if (ptr)
headers = ptr+2;
else
{
ptr = strstr (client->refbuf->data, "\n");
if (ptr)
headers = ptr+1;
}
}
```
Which unfortunately matches on the \r\n on the header, and misses the \n on the end of the password. So it uses the password a \n and the first line of the headers as the password, which fails and it rejects the connection.
For my purposes I've fix it by changing the code to:
```
/* Get rid of trailing \r\n or \n after password */
ptr = strstr (client->refbuf->data, "\n");
if (ptr)
{
headers = ptr+1;
while ( ( ptr > client->refbuf->data ) && ( ptr[-1]=='\r' ) )
{
ptr--;
}
}
```
So it finds the first \n and backtracks to remove any \r's
Obviously this is an edge case, in general people using BUTT will use icecast native connections, and most source client don't use mixed line endings. But I think my fixed version is probably more efficient on average anyway, so I think it should be safe to add.
I was going to try and submit a patch, but it looks like the code has moved on since the last version released, though even that didn't seem to use the latest changes at the time. So I'm not sure what is happening in that area. I'll leave this here and if its of any use then please include it. If you can shed more light on the evolution of the file and its worth it I can clone the latest version and test and if necessary make a patch for it.
Regards
GaryThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2265Malformed 'max-listeners' in icecast.xml causes Segmentation Fault2017-10-05T10:40:40Zicy2005Malformed 'max-listeners' in icecast.xml causes Segmentation FaultHi all!
How to reproduce:
1. Put the following under <icecast><mount>:
<max-listeners/>
2. Run /usr/bin/icecast2 -c /etc/icecast2/icecast.xml
3. Confirm if it crashes with "Segmentation Fault"
Hotfix:
1. Change <max-listeners/...Hi all!
How to reproduce:
1. Put the following under <icecast><mount>:
<max-listeners/>
2. Run /usr/bin/icecast2 -c /etc/icecast2/icecast.xml
3. Confirm if it crashes with "Segmentation Fault"
Hotfix:
1. Change <max-listeners/> to a value, e.g.:
<max-listeners>100</max-listeners>
Thanks!Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2292Relay slave fails to connect over Amazon ELB2018-11-10T12:48:22ZRaz YalovRelay slave fails to connect over Amazon ELBTrying to configure a slave Icecast server through an Amazon Elastic Load Balancer (ELB), the socket never connects.
Log shows this error:
WARN slave/update_from_master Relay slave failed to contact master server to fetch stream list...Trying to configure a slave Icecast server through an Amazon Elastic Load Balancer (ELB), the socket never connects.
Log shows this error:
WARN slave/update_from_master Relay slave failed to contact master server to fetch stream list
using strace it seems like the connection never establishes on the socket's opening level, but there is not description of the exact error.
Replacing the load balancer DNS with the IP of one of the servers that are behind the ELB does seems to work.
login as the icecast user I was able to verify that the same information does work directly via telnet and curl. Only the icecast connection fails through the ELB.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2257Icecast hangs after several hours running2017-10-05T10:40:40ZDaniel LafraiaIcecast hangs after several hours runningI have a couple of Icecast servers at Digital Ocean used as a relay to our main Icecast server at AWS. For some reason the edge server (the one receiving connections from end users) hangs completely.
I had to setup Supervisord to do an ...I have a couple of Icecast servers at Digital Ocean used as a relay to our main Icecast server at AWS. For some reason the edge server (the one receiving connections from end users) hangs completely.
I had to setup Supervisord to do an HTTP request to status.xsl to determine if it's up, so it can be restarted when it happens (status.xsl request times out). Actually this happens both servers, same behavior hanging every 1 or 2 days or so.
This is not a busy streaming server (about 400 listeners peak each). When it hangs sometimes it's not on peak hours, I've seen it happening early morning.
Error_log stops longing when it happens, so there's not much information there (using loglevel 3).
This icecast server is running in a docker container, just like the main server. I'm starting this docker image with ulimit 1024:1024 for nofile.
How can I provide you with more info so we can see if this is a bug?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2256Icecast 2.4.2 hangs after several hours running2017-10-05T10:40:40ZDaniel LafraiaIcecast 2.4.2 hangs after several hours runningI have a couple of Icecast servers at Digital Ocean used as a relay to our main Icecast server at AWS. For some reason the edge server (the one receiving connections from end users) hangs completely.
I had to setup Supervisord to do an ...I have a couple of Icecast servers at Digital Ocean used as a relay to our main Icecast server at AWS. For some reason the edge server (the one receiving connections from end users) hangs completely.
I had to setup Supervisord to do an HTTP request to status.xsl to determine if it's up, so it can be restarted when it happens (status.xsl request times out). Actually this happens both servers, same behavior hanging every 1 or 2 days or so.
This is not a busy streaming server (about 400 listeners peak each). When it hangs sometimes it's not on peak hours, I've seen it happening early morning.
Error_log stops longing when it happens, so there's not much information there (using loglevel 3).
This icecast server is running in a docker container, just like the main server. I'm starting this docker image with ulimit 1024:1024 for nofile.
How can I provide you with more info so we can see if this is a bug?Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2284Icecast segfaults on startup and shutdown2018-07-02T00:38:16ZBrendonIcecast segfaults on startup and shutdownUsing the latest 2.4.3 with SSL on Debian 8 x64 (happens with SSL disabled as well). Running icecast using daemontools. This also happened with 2.4.2 being started with upstart. Startup script is:
```
exec /usr/local/bin/icecast -c /etc...Using the latest 2.4.3 with SSL on Debian 8 x64 (happens with SSL disabled as well). Running icecast using daemontools. This also happened with 2.4.2 being started with upstart. Startup script is:
```
exec /usr/local/bin/icecast -c /etc/icecast/icecast.xml
```
I've noticed that the icecast process segfaults on both startup and shutdown.
Shutdown:
```
Aug 24 14:50:01 ngradio-staging kernel: [80171.821413] icecast[16264]: segfault at 48 ip 000000000040fa8e sp 00007f2af4087dd0 error 4 in icecast[400000+34000]
```
Startup:
```
Aug 24 14:41:02 ngradio-staging kernel: [79632.697742] icecast[14984]: segfault at 0 ip 00007fc773ea3c3a sp 00007fc775798e18 error 4 in libc-2.19.so[7fc773e22000+1a2000]
```
Observations:
- Happens 100% of the time the process is stopped.
- Happens nearly 100% of the time the process is started, and at times can happen 5-10 times before the icecast process will start. Sometimes I can't get the process to start at all when I'm starting it manually via the cli (tried 10-20 times then gave up).
- Happens with the liquidsoap processes trying to connect and with liquidsoap completely down.
- Nothing seems to be correlated with these segfaults, nor with this happening once or multiple times before the process ultimately starts.
- I don't get a segfault on startup when running Icecast via valgrind, but I do when running directly on the cli, via strace, or via daemontools.
- Sometimes if I start / restart icecast a bunch via daemontools, I can't get the process to start up at all. A reboot seems to be the only thing that helps.
I uploaded my Icecast config and some valgrind output in #2283. This is the tail end of the strace output:
```
munmap(0x7f23bacb1000, 4096) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
write(7, "[2016-08-24 14:53:33] INFO conn"..., 118) = 118
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
write(7, "[2016-08-24 14:53:33] INFO conn"..., 836) = 836
poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, 300 <unfinished ...>
+++ killed by SIGSEGV +++
```
Let me know if I can provide any other info. As of right now, this is simply a nuisance, but without daemontools restarting the process over and over until it finally does start up, this would probably be a blocker.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2255Invalid XML in Icecast statistics output due to lack of escaping2018-04-16T22:12:13ZThomas B. RückerInvalid XML in Icecast statistics output due to lack of escapingIcecast version 2.3.3-2ubuntu1.14.04.1 , when reporting statistics via API calls to http://%s:%d/admin/stats.xml, returns this invalid XML:
```
<icestats>
<source mount="/radio">
<Listeners>1</Listeners>
<listener>
<IP>23.2.9...Icecast version 2.3.3-2ubuntu1.14.04.1 , when reporting statistics via API calls to http://%s:%d/admin/stats.xml, returns this invalid XML:
```
<icestats>
<source mount="/radio">
<Listeners>1</Listeners>
<listener>
<IP>23.2.9.2</IP>
<UserAgent>Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12F70 [FBAN/FBIOS;FBAV/46.0.0.54.156;FBBV/18972819;FBDV/iPhone5,3;FBMD/iPhone;FBSN/iPhone OS;FBSV/8.3;FBSS/2; FBCR/AT&T;FBID/phone;FBLC/en_US;FBOP/5]</UserAgent>
<Connected>0</Connected>
<ID>2634887</ID>
</listener>
</source>
</icestats>
```
Note the unescaped &T; which is an undefined XML entity "T", and causes parsers to explode.
Expected behavior: text inside blocks should be html escaped or enclosed in a CDATA block, if I remember my XML correctly.
[Originally reported on github](https://github.com/xiph/Icecast-Server/issues/3) by [kenrestivo](https://github.com/kenrestivo)Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2283Streaming over SSL disconnects2020-02-26T00:04:46ZBrendonStreaming over SSL disconnectsI reported this via IRC but wanted to make sure a proper bug report gets filed before moving on.
I'm building a streaming radio service for Newgrounds.com. More than one application has an embedded radio player and these applications ar...I reported this via IRC but wanted to make sure a proper bug report gets filed before moving on.
I'm building a streaming radio service for Newgrounds.com. More than one application has an embedded radio player and these applications are all served over SSL.
In order to avoid mixed content warnings, I built Icecast 2.4.3 with SSL support so I could get status info and serve the stream over SSL as well.
(None of the Debian or Ubuntu packages have been built with SSL yet for some reason.)
I'm using Debian 8 x64. libssl is 1.0.1t (which is the latest 1.0.1 LTS version). liquidsoap 1.1.1 is the source and connects to Icecast via port 80 on localhost (both liquidsoap and icecast are on the same VM).
I have six mounts configured all the same. liquidsoap is re-encoding the mp3s at a constant bitrate of 128k. I've uploaded a stripped down Icecast config.
Here is what happens: normally, streaming over SSL works perfectly fine. But sometimes, either right at stream start or at some seemingly random amount of time later, one of the mounts becomes "corrupted." The web player (using a simple <audio> tag) quickly buffers and disconnects. VLC reconnects and gets disconnected over and over.
I've tested this on my local network over wifi using the web player, VLC, and iTunes, and with ServeStream on Android over cellular. All same result.
If I connect to the stream via port 80, I do not get disconnected. I get disconnected from the stream ONLY when streaming over SSL and ONLY when the mount becomes corrupted.
Observations:
- This happens on every mount seemingly at random, but it seems that only ONE mount becomes corrupted at a time.
- Doesn't seem to be triggered by any one song, a track change, or anything else station related that I can find.
- Happens if I use ogg or mp3.
- Shutting down the liquidsoap instance for the corrupted mount, waiting a minute or so (a quick restart doesn't seem to fix it) and then restarting liquidsoap seems to resolve the issue (at least temporarily).
- Nothing in the logs that I can see, even with debug logging on:
[2016-08-21 20:30:08] DBUG stats/modify_node_event update "/electronic" listeners (1)
[2016-08-21 20:30:08] DBUG format/format_check_http_buffer processing pending client headers
[2016-08-21 20:30:08] DBUG client/client_send_bytes Client connection died
[2016-08-21 20:30:08] DBUG source/source_main Client removed
[2016-08-21 20:30:08] INFO source/source_main listener count on /electronic.mp3 now 0
These cycle over and over again as the client disconnects and reconnects. I can find nothing else in any of the logs on the system.
- This happens on both staging and production which is on two separate servers.
I was asked to run Icecast using valgrind. We saw lots of SSL errors, so one possible issue could be a buggy system libssl (which I do not think is the case at this point). I even got the latest OpenSSL 1.0.2h built and then built Icecast against that to rule out 1.0.1t causing a bunch of errors.
I will upload the Valgrind output for both 1.0.1t and 1.0.2h.
I simply started Icecast and then shut it down via ctrl-c. This was NOT running while experiencing a corrupted mount.
That's about as much information as I think I have at this point. I have decided to abandon using SSL for the streams as it simply does not seem to be production ready at this point. This will cause mixed content errors in our applications, but streaming over http seems much more stable.
I'd be happy to help provide more information if requested.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2254Replace autogen.sh with a simple wrapper around autoreconf2017-10-05T10:40:40ZMarvin ScholzReplace autogen.sh with a simple wrapper around autoreconfCurrently the autogen.sh script does a lot of stuff which is mostly not needed anymore,
given that autoreconf can do all of that and possibly even better.Currently the autogen.sh script does a lot of stuff which is mostly not needed anymore,
given that autoreconf can do all of that and possibly even better.Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2270If relay with on-demand's source goes down, on_demand is no longer reported i...2020-10-11T11:40:22ZdonicsIf relay with on-demand's source goes down, on_demand is no longer reported in status-json.xsl when source returns.If you set up a relay with on-demand=1 in the relay settings, status-json.xsl will report the setting as on_demand=1. This is great, and helps with calculating total viewers on a source.
One thing I have found, though, is that if the so...If you set up a relay with on-demand=1 in the relay settings, status-json.xsl will report the setting as on_demand=1. This is great, and helps with calculating total viewers on a source.
One thing I have found, though, is that if the source goes down, the relay will stop reporting on_demand status-json.xsl. This continues even when the source comes back up. The only way to get on_demand reporting back is to restart the service.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2249Spaces in Web and Admin path break new include helper for libxslt2017-10-05T10:40:40ZMarvin ScholzSpaces in Web and Admin path break new include helper for libxsltThe custom include handler that resolves paths, making it possible for web files to include admin files breaks if the path contains a space, as this gets somehow encoded to %20 apparently by one of the xml helper functions I am using to ...The custom include handler that resolves paths, making it possible for web files to include admin files breaks if the path contains a space, as this gets somehow encoded to %20 apparently by one of the xml helper functions I am using to build the path.Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2269Allow certificate rotation2018-06-15T20:37:13ZFinnAllow certificate rotationI'd like to re-issue my SSL certs somewhat frequently and have Icecast reload them without kicking off all my users. Perhaps with a SIGHUP?
Specifically, I'm using Let's Encrypt which automatically re-issues certs every 90 or so days, a...I'd like to re-issue my SSL certs somewhat frequently and have Icecast reload them without kicking off all my users. Perhaps with a SIGHUP?
Specifically, I'm using Let's Encrypt which automatically re-issues certs every 90 or so days, and it'd be nice to be able to set Icecast on a cronjob to re-read them after they get reissued.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2248File extension check ignores trailing characters2017-10-05T10:40:40ZMarvin ScholzFile extension check ignores trailing charactersThe `util_check_valid_extension` function will ignore any characters after a matched file extension, so that `xsl`, `xslt` and `xslfoooo` will all return `XSLT_CONTENT`, even though the last one really should not.
Additionally there is ...The `util_check_valid_extension` function will ignore any characters after a matched file extension, so that `xsl`, `xslt` and `xslfoooo` will all return `XSLT_CONTENT`, even though the last one really should not.
Additionally there is a check for `htm` and after that another one for `html`, but the first check will always match even in the case of html, so that code is actually useless and never execute.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2247XSLs are returned in plaintext if trailing dot is appended to the URL (Window...2018-04-16T22:12:13ZMarvin ScholzXSLs are returned in plaintext if trailing dot is appended to the URL (Windows only)If requesting an xsl file, anyone can get a unprocessed version of that file, possibly exposing internal information to the user, by appending a dot to the requested filename:
```
http://localhost:8000/status.xsl.
```
Only Windows is...If requesting an xsl file, anyone can get a unprocessed version of that file, possibly exposing internal information to the user, by appending a dot to the requested filename:
```
http://localhost:8000/status.xsl.
```
Only Windows is affected. This is due to the way the Windows API handles filenames, as it strips the trailing dot and will assume status.xsl instead of the version with the trailing dot.
*Unix and Linux builds were never affected.*
(See CVE-2005-0837 and #635)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2199Icecast listener count negative under special circumstances2018-04-16T14:24:46ZMarvin ScholzIcecast listener count negative under special circumstancesAs reported by SimAV on IRC (thanks a lot), it can happen under special circumstances that the Icecast global listener count becomes a negative number.
It seems this is a very special case where `format_check_http_buffer` has an interna...As reported by SimAV on IRC (thanks a lot), it can happen under special circumstances that the Icecast global listener count becomes a negative number.
It seems this is a very special case where `format_check_http_buffer` has an internal problem (see log). As far as I have investigated, this is caused because `ebml_create_client_data` returns -1. We need to investigate why this leads to a wrong listener count.
Some more information attached.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2263Add mime.types paths for other distros2020-10-11T14:45:20ZMarvin ScholzAdd mime.types paths for other distrosWe should add some more mime.types paths, seems the current one we have does not work on FreeBSD
and OS X uses a different one.
See [this](https://groups.google.com/forum/#!topic/golang-codereviews/fIw6mRzai4U) for some more paths that ...We should add some more mime.types paths, seems the current one we have does not work on FreeBSD
and OS X uses a different one.
See [this](https://groups.google.com/forum/#!topic/golang-codereviews/fIw6mRzai4U) for some more paths that seems to be usual.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2198status-json.xsl produces invalid output if field contains only "-" and option...2017-10-14T21:47:27ZZalexstatus-json.xsl produces invalid output if field contains only "-" and optional whitespaceWhen my track *hasn't* title in *tags*, Icecast shows *`-`* instead of a blank line,(I suppose this status sends the client, mpd in my case, to Icecast server) so, I get json like this (see example) and this json isn't valid because *`"...When my track *hasn't* title in *tags*, Icecast shows *`-`* instead of a blank line,(I suppose this status sends the client, mpd in my case, to Icecast server) so, I get json like this (see example) and this json isn't valid because *`"title" : -`* instead *`"title" : "-"`* . I checked it here - http://jsonlint.com/ So, I cant't do `json_decode()`, function returns `null`
```
{
"icestats": {
"admin": "admin@admin",
"host": "host.com",
"location": "Moscow",
"server_id": "Icecast 2.4.2",
"server_start": "Fri, 15 May 2015 16:25:24 +0300",
"server_start_iso8601": "2015-05-15T16:25:24+0300",
"source": [
{
"audio_info": "channels=2;samplerate=44100;bitrate=192",
"channels": 2,
"genre": "various",
"listener_peak": 3,
"listeners": 0,
"listenurl": "http://mds.planeset.ru:8000/mds.mp3",
"samplerate": 44100,
"server_description": "Трансляции Модель Для Сборки
музыка",
"server_name": "Модель для сборки - музыка",
"server_type": "audio/mpeg",
"stream_start": "Fri, 15 May 2015 16:25:33 +0300",
"stream_start_iso8601": "2015-05-15T16:25:33+0300",
"title": -,
"dummy": null
},
{
"audio_info": "channels=2;samplerate=44100;bitrate=192",
"channels": 2,
"genre": "various",
"listener_peak": 10,
"listeners": 9,
"listenurl": "http://mds.planeset.ru:8000/mds_voice.mp3",
"samplerate": 44100,
"server_description": "Трансляции Модель Для Сборки -
голос",
"server_name": "Модель для сборки - голос",
"server_type": "audio/mpeg",
"stream_start": "Fri, 15 May 2015 16:25:33 +0300",
"stream_start_iso8601": "2015-05-15T16:25:33+0300",
"title": "Фред Саберхаген - Доброжил",
"dummy": null
}
]
}
}
```
This is example of json, as You can see in first case I have `title: -` because of it I can not json_decode.
There is file xml2json.xslt from Doeke Zanstra [https://github.com/doekman/xml2json-xslt][1] on server. This file, I guess, convert xml to json and maybe there is a way to add new rule to convert `-` to `null` in blank `title` line, but I don't know how I can do it.
[1]: https://github.com/doekman/xml2json-xsltIcecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://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/2191Icecast can be crashed remotely if stream_auth is enabled.2018-04-16T22:12:13ZThomas B. RückerIcecast can be crashed remotely if stream_auth is enabled.Downstream bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782120
Icecast can be killed by anyone with a simple HTTP request when
<authentication type="url"> is used and a stream_auth handler is
defined.
Example configura...Downstream bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782120
Icecast can be killed by anyone with a simple HTTP request when
<authentication type="url"> is used and a stream_auth handler is
defined.
Example configuration:
```
<mount>
<mount-name>/test.ogg</mount-name>
<authentication type="url">
<option name="stream_auth" value="http://localhost/auth"/>
</authentication>
</mount>
```
Proof of concept exploit:
```
curl "http://stream.example.org:8000/admin/killsource?mount=/test.ogg"
```
This happens if no logon credentials are sent with the request. The crash happens regardless of a source client being connected to the vulnerable mountpoint.
This will be released in a security release 2.4.2 today.
CVE-2015-3026Icecast 2.4.2Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2259[PATCH] Master-Slave Aggregating Relay (multiple master setup)2017-10-05T10:40:40ZMarvin Scholz[PATCH] Master-Slave Aggregating Relay (multiple master setup)We got a pull-request on Github by [greenbender](https://github.com/greenbender):
> This pull request adds support for multiple Master-Slave relays. Something I am calling a Master-Slave Aggregating Relay.
>
> A couple of people have a...We got a pull-request on Github by [greenbender](https://github.com/greenbender):
> This pull request adds support for multiple Master-Slave relays. Something I am calling a Master-Slave Aggregating Relay.
>
> A couple of people have asked for this feature in the past and were referred to the Single-Broadcast Relay, which is OK provided you know the specific mountpoints that you want to relay ahead of time.
>
> If you are in a position where you want to relay mountpoints for more than one the master server, and one or more of the master servers adds and removes mountpoints dynamically or if you are unable to know what mountpoints are available ahead of time then this gives you the ability to aggregate all mountpoints for any numbers of master servers.
>
> Namespacing is also supported to prevent name clashes for mountpoints being relayed from different servers.
The patch can be found here:
```
https://github.com/xiph/Icecast-Server/pull/5.patch
```
For more information, see the [original Github Pull-Request](https://github.com/xiph/Icecast-Server/pull/5)!Icecast 2.5.2Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2179URL Auth with iOS not working correctly2017-10-05T10:40:40ZSebastianURL Auth with iOS not working correctlyHi guys,
when using an IOS device like iPad or iPhone the function "url_add_client" in the file "auth_url.c" seems not to forward all parameters correctly to the authentication system (in my case verify.php).
The username is missing as...Hi guys,
when using an IOS device like iPad or iPhone the function "url_add_client" in the file "auth_url.c" seems not to forward all parameters correctly to the authentication system (in my case verify.php).
The username is missing as you can see in the example below (PHP_AUTH_USER is empty).
After the initial "HTTP/1.0 401 Authentication Required" three GET requests are sent by mobile clients (Android, as well as iPhones or iPads). I checked that with Wireshark. On Android phones the username is never empty, that's why it is always working there.
On iPhones and iPads we have the result below.
The following data is captured from the requests of Icecast to the authentication system (verify.php).
Have a look at the cut off "HTTP_AUTHORIZATION" and the missing username in "PHP_AUTH_USER"
Do you have any idea what is going on there?
New request:
```
CONTENT_TYPE: application/x-www-form-urlencoded
CONTENT_LENGTH: 349
HTTP_USER_AGENT: Icecast 2.4.99.1
HTTP_HOST: www.domain.com
HTTP_AUTHORIZATION: Basic dm9sbDpob3JzdA==
HTTP_ACCEPT: */*
HTTP_CONTENT_TYPE: application/x-www-form-urlencoded
HTTP_CONTENT_LENGTH: 349
PHP_AUTH_USER: peter
PHP_AUTH_PW: pan
```
New request:
```
CONTENT_TYPE: application/x-www-form-urlencoded
CONTENT_LENGTH: 340
HTTP_USER_AGENT: Icecast 2.4.99.1
HTTP_HOST: www.domain.com
HTTP_AUTHORIZATION: Basic OmhvcnN0
HTTP_ACCEPT: */*
HTTP_CONTENT_TYPE: application/x-www-form-urlencoded
HTTP_CONTENT_LENGTH: 340
PHP_AUTH_USER:
PHP_AUTH_PW: pan
```
New request:
```
CONTENT_TYPE: application/x-www-form-urlencoded
CONTENT_LENGTH: 340
HTTP_USER_AGENT: Icecast 2.4.99.1
HTTP_HOST: www.domain.com
HTTP_AUTHORIZATION: Basic OmhvcnN0
HTTP_ACCEPT: */*
HTTP_CONTENT_TYPE: application/x-www-form-urlencoded
HTTP_CONTENT_LENGTH: 340
PHP_AUTH_USER:
PHP_AUTH_PW: pan
```
Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2258Absolute paths when relaying2018-06-15T20:47:52ZmschmidAbsolute paths when relayingI've set up a couple of relays that were/still are properly running under icecast 2.3.2 with its separate mount point configuration, while they do not work under 2.4.0 and later.
The problem seems to be tied to how the client's requests ...I've set up a couple of relays that were/still are properly running under icecast 2.3.2 with its separate mount point configuration, while they do not work under 2.4.0 and later.
The problem seems to be tied to how the client's requests are interpreted. On the newer version it seems to be forbidden to request the full path, while the old did support this. But relays always create the full path in the links.
the server'n name is 'mediaserv'.
the paths are configured like this (debian defaults, no chroot):
<basedir>/usr/share/icecast2</basedir>
<logdir>/var/log/icecast2</logdir>
<webroot>/usr/share/icecast2/web</webroot>
<adminroot>/usr/share/icecast2/admin</adminroot>
a relay example is:
<relay>
<server>mms-live.online.no</server>
<port>80</port>
<mount>/p4_norge_mp3_hq</mount>
<local-mount>/p4</local-mount>
<on-demand>1</on-demand>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
</relay>
The content of
http://mediaserv:8000/usr/share/icecast2/web/p4.m3u
is:
http://mediaserv:8000/usr/share/icecast2/web/p4
which does no longer work.
When I reduce it to http://mediaserv:8000/p4, it's working perfectly.
Shouldn't all the links be relative?
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2246Check Icecast2 for support to whatever result of #22332018-06-16T21:36:36ZPhilipp SchafftCheck Icecast2 for support to whatever result of #2233Icecast2 should support whatever the outcome is to icecast-libshout#2233. This ticket should be updated once icecast-libshout#2233 is closed to list what needs to be done on the server side.Icecast2 should support whatever the outcome is to icecast-libshout#2233. This ticket should be updated once icecast-libshout#2233 is closed to list what needs to be done on the server side.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2245Move TLS options out of <paths>2018-06-15T20:50:30ZPhilipp SchafftMove TLS options out of <paths>The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/23272.4.99.1 leaks filedescriptors?2020-02-25T08:58:43ZHugo2.4.99.1 leaks filedescriptors?Hi,
We've upgraded some of our production icecast servers to 2.4.99.1 this morning (from 2.4.2, because of the better TLS support). 1 one the 8 upgraded servers is expierencing problems which seem to be known as a "filedescriptor leak"....Hi,
We've upgraded some of our production icecast servers to 2.4.99.1 this morning (from 2.4.2, because of the better TLS support). 1 one the 8 upgraded servers is expierencing problems which seem to be known as a "filedescriptor leak". The server does not respond to new connections anymore, but seems to handle a lot of existing connections still fine. With netstat and lsof a lot of CLOSE_WAIT connections show up:
$ sudo lsof -np 28035 | wc -l
12895
$ sudo lsof -np 28035 | grep CLOSE_WAIT | wc -l
5973
The other 7 servers do not experience this problem (yet). The maximum amount of listeners today was about 6500 per server (on a number of channels).
Could it be that icecast is leaking filedescriptors somehow in situations that are not always triggered (since not all servers encounter this problem)?
All servers are running the same kernel; 4.1.39 and the installation is identical on all systems.
Any suggestions what could be done to debug this problem? It would be nice if we could reproduce this, but I have no clue what could cause this.
Regards,
Hugohttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2328When configuration file is invalid, icecast hangs indefinitely2018-06-16T20:30:29ZMarcin LewandowskiWhen configuration file is invalid, icecast hangs indefinitelyI am running icecast 2.4.3 on ubuntu 16.04, compiled from sources.
I have found out that if given XML config has invalid syntax, it outputs error but do not terminate the process. It is quite painful as it is not easily possible to chec...I am running icecast 2.4.3 on ubuntu 16.04, compiled from sources.
I have found out that if given XML config has invalid syntax, it outputs error but do not terminate the process. It is quite painful as it is not easily possible to check if service is running or not, as process exists.
```
/usr/bin/icecast -c /etc/icecast/icecast.xml
/etc/icecast/icecast.xml:1: parser error : Document is empty
FATAL: error parsing config file (/etc/icecast/icecast.xml)
XML config parsing error
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2237[PATCH] Detect Keyframes in WebM streams2018-03-06T12:49:37ZJoseph Wallace[PATCH] Detect Keyframes in WebM streamsThe existing WebM plugin will mark the start of any cluster as a sync point. This causes problems for web browsers, which tend to strictly demand that video streams are started on a keyframe.
The WebM specs call for a keyframe being the...The existing WebM plugin will mark the start of any cluster as a sync point. This causes problems for web browsers, which tend to strictly demand that video streams are started on a keyframe.
The WebM specs call for a keyframe being the first video frame in a cluster if the cluster contains a keyframe, but they do not require clusters to contain any keyframes at all.
This patchset:
1. implements some EBML parsing functions, to identify clusters accurately instead of assuming any occurrence of the cluster magic number is a cluster header.
2. detects if a WebM stream contains a track of type video.
3. examines the SimpleBlocks of each cluster to determine if the first video track block is marked as a keyframe.
If the first video block is a keyframe, the cluster is marked as a sync point. If the first video block is NOT a keyframe, the cluster is not marked as a sync point.
If a determination cannot be made in the first 4K of the cluster, it's optimistically marked as a sync point, since it's most likely an audio-only stream.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2231process hangs after HUP signal2023-05-08T09:49:13Zhk_netprocess hangs after HUP signalwe got icecast 2.4.2 running fine, but some times after several HUP signals for logrotation the process hangs, no more listening on its tcp-socket nor logging anything.
stopping and restarting helps to get the stream working again, but ...we got icecast 2.4.2 running fine, but some times after several HUP signals for logrotation the process hangs, no more listening on its tcp-socket nor logging anything.
stopping and restarting helps to get the stream working again, but we do have no clue how to find the issue causing this behavior.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2226Adding <mount-title> for mountpoints2018-11-10T15:54:39ZvtangerAdding <mount-title> for mountpointsAs there are a number of semi-defective clients which do not transmit a description/title as well as people out there who cannot reliably enter the display title into their client configuration, such an override-option in the configurat...As there are a number of semi-defective clients which do not transmit a description/title as well as people out there who cannot reliably enter the display title into their client configuration, such an override-option in the configuration would come handy. Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2225Make listen backlog customizable2018-09-28T14:05:00ZMarvin ScholzMake listen backlog customizableExcerpt from a mail we got on the list:
On 02/19/2015 03:07 PM, Stephan Leemburg wrote:
> I am working for the NPO, the Dutch Public Broadcasting agency.
>
> We do a lot of icecast streaming. We run at least 20 icecast server
> instanc...Excerpt from a mail we got on the list:
On 02/19/2015 03:07 PM, Stephan Leemburg wrote:
> I am working for the NPO, the Dutch Public Broadcasting agency.
>
> We do a lot of icecast streaming. We run at least 20 icecast server
> instances on our media streaming cluster. [...]
>
> We ran into an issue that clients which where connecting to our streams
> seemed to be 'hanging' on the connection setup frequently. The client
> 'thinks' it is connected, but no data.
>
> People suggested that it probably had to do with the poll() call. So, I
> looked into that.
>
> I found that the issue was actually caused by the very low listen
> backlog (5).
> On our clusters, we typically set this to 8192. Yes it is high, but we
> do a _lot_ of streaming and host very high volume websites.
Attached are the submitted patches for 2.4, 2.5 and 2.3.3
Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2173Max duration support for stream dumpfiles2022-03-22T17:48:23ZThomas B. RückerMax duration support for stream dumpfilesWe've received a request on this topic:
```
My suggestion is that the dump-file tag have an interval option or tag so
that it creates a new dump file based on this interval, and named based
on some sort of dump-file-name tag which wou...We've received a request on this topic:
```
My suggestion is that the dump-file tag have an interval option or tag so
that it creates a new dump file based on this interval, and named based
on some sort of dump-file-name tag which would use BASH naming variables
to name it.
```
http://lists.xiph.org/pipermail/icecast/2015-March/013209.html
Basically boils down to setting a duration and after that reopening the dump file. We already support strftime patterns in the file name.
I have received a patch for this against 2.3.2 and we'll evaluate if it can be reused or at least used as inspiration.
Optional related feature: dump files triggered / turned on/off through admin request.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2223Icecast does not support HEAD requests2018-11-30T12:05:07ZOndra PelechIcecast does not support HEAD requestsalso reported on [Github](https://github.com/xiph/Icecast-Server/issues/2)
this makes transcodig in browser via javascript impossible
affects:
* [Aurora.js](https://github.com/audiocogs/aurora.js/issues/135)
* [Ampache](https://githu...also reported on [Github](https://github.com/xiph/Icecast-Server/issues/2)
this makes transcodig in browser via javascript impossible
affects:
* [Aurora.js](https://github.com/audiocogs/aurora.js/issues/135)
* [Ampache](https://github.com/ampache/ampache/issues/933)
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2222m3u link contents2018-11-18T10:50:03Zitmmediam3u link contentswhen attempting to play a stream from the links on the icecast server web interface the contents of the m3u file uses the wrong port number.
this may be related to ticket #2180
when connected to the server web interface with ssl ( http...when attempting to play a stream from the links on the icecast server web interface the contents of the m3u file uses the wrong port number.
this may be related to ticket #2180
when connected to the server web interface with ssl ( https ) on port 8001 ( audio clients connect via port 8000 without ssl ) the contents of the m3u file when clicking on the icon, contains port 8001 instead of 8000. the other links/icons ( vclt and xpsf ) seem to be correct.
audio streams are anonymous relays of streams from web sites accessed by clients ( winamp ) on a local area network. this issue happens with any/all configured relays.
M3U contents: ( wrong port )
`http://192.168.xxx.xxx:8001/mountpoint`
NOTE: This should be
`http://192.168.xxx.xxx:8000/mountpoint`
or
`http://servername:8000/mountpoint`
VCLT contents: ( ok ? )
```
STREAMURL=http://servername:8000/mountpoint
TITLE=
SERVER_NAME=Orange Cty - For more ...
DESCRIPTION=Unspecified description
SIGNALINFO=
GENRE=Railroad Radio Scanner
==
```
XPSF contents: ( ok ? )
```xml
<?xml version="1.0" encoding="UTF-8"?>
<playlist xmlns="http://xspf.org/ns/0/" version="1">
<title></title>
<creator></creator>
<trackList>
<track>
<location>http://servername:8000/mountpoint</location>
<title></title>
<annotation>Stream Title: Orange Cty - For more ...
Stream Description: Unspecified description
Content Type:audio/mpeg
Bitrate: 28
Current Listeners: 1
Peak Listeners: 1
Stream Genre: Railroad Radio Scanner</annotation>
<info>http://www.streamwebsite.url</info>
</track>
</trackList>
</playlist>
```
parts of icecast.xml:
```xml
<!-- You may have multiple <listener> elements -->
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</listen-socket>
<!-- admin port on 8001 using ssl -->
<!-- added/enabled Thu Jan 22 08:31:43 PST 2015 -->
<listen-socket>
<port>8001</port>
<ssl>1</ssl>
</listen-socket>
<relay>
<!-- http://railaudio.stream-host-name:stream-port/ -->
<server>railaudio.stream-host-name</server>
<port>stream-port</port>
<mount>/</mount>
<local-mount>/mountpoint</local-mount>
<on-demand>1</on-demand>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
</relay>
```
connecting to admin panel at:
`https://192.168.xxx.xxx:8001/`
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2205Allow icy-description override with stream-description from config2020-05-14T08:51:14ZMarvin ScholzAllow icy-description override with stream-description from configCurrently only the stream-name will override the icy-name header, we should implement the same handling for stream-description and icy-description as there are source clients that do not sent those headers.
(See [18543] and #1359)Currently only the stream-name will override the icy-name header, we should implement the same handling for stream-description and icy-description as there are source clients that do not sent those headers.
(See [18543] and #1359)Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2202Hardcoded HTTP protocol verification for master-slave relaying2018-06-15T20:53:24ZMarvin ScholzHardcoded HTTP protocol verification for master-slave relayingIf using master slave relaying, Icecast tries to download a .txt file with an overview of the mountpoints connected on the master. There the code has a hardcoded check for "HTTP/1.0", that means it will fail if Icecast ever uses HTTP/1.1...If using master slave relaying, Icecast tries to download a .txt file with an overview of the mountpoints connected on the master. There the code has a hardcoded check for "HTTP/1.0", that means it will fail if Icecast ever uses HTTP/1.1 instead, which is not very good.
A proper check should be used there.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2171Improve https handling of Icecast web ui and generated files2018-11-09T07:18:34ZThomas B. RückerImprove https handling of Icecast web ui and generated filesCurrently some things break if Icecast runs with HTTPS on the primary port.
We should implement proper handling not to return HTTP URLS in such cases.
Right now this either breaks things or will make them insecure.Currently some things break if Icecast runs with HTTPS on the primary port.
We should implement proper handling not to return HTTP URLS in such cases.
Right now this either breaks things or will make them insecure.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2201network throughput limited at 70mbps2018-07-07T09:17:24Zwilson chuanetwork throughput limited at 70mbpsHi I have setup 3 icecast servers for eradioportal.com. These are running in a hyperV environment using CentOS v6.6
I have noticed that despite being on a 1gbps connection, the maximum network throughput i am getting is somewhere aroun...Hi I have setup 3 icecast servers for eradioportal.com. These are running in a hyperV environment using CentOS v6.6
I have noticed that despite being on a 1gbps connection, the maximum network throughput i am getting is somewhere around the 70mbps only.
Is this a bug? or is this a misconfiguration error?
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2169Improved mountpoint metadata manipulation support through /admin calls2018-11-10T12:59:34ZThomas B. RückerImproved mountpoint metadata manipulation support through /admin callsCurrently we expose this mostly as the old style shoutcast metadata hack requires the data to arrive separate from the stream. This is limited to "title".
We should expose a unified interface that allows updating all mountpoint metadata...Currently we expose this mostly as the old style shoutcast metadata hack requires the data to arrive separate from the stream. This is limited to "title".
We should expose a unified interface that allows updating all mountpoint metadata, including that of the stream/container.
This would make things a lot more flexible and enable new use cases, like adjusting mountpoint information without having to reconnect the source.
Assigned to 2.5.0, pending feasibility checks.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2200icecast stats addition (per mount cumulative listener counter)2018-07-07T09:19:54Zddndukkicecast stats addition (per mount cumulative listener counter)Currently in icecast statistics available counter like 'hit count' only globally in <icecasts/> node. I mean 'listener_connections'
It will be very good to add per-mount counter like that (accumulated counter of listener connections).
s...Currently in icecast statistics available counter like 'hit count' only globally in <icecasts/> node. I mean 'listener_connections'
It will be very good to add per-mount counter like that (accumulated counter of listener connections).
so it appears in /icecasts/source/ node with name like 'listener_connections'.
<icestats>
<listener_connections>3</listener_connections>
<source mount="/test">
<listener_connections>2</listener_connections>
...
</source>
</icecasts>
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2168Icecast should expose the YP server messages to the admin status pages per mount2018-06-16T22:44:50ZThomas B. RückerIcecast should expose the YP server messages to the admin status pages per mountThere are hundreds if not thousands of streams that fail to list properly on dir.xiph.org and it's obvious that nobody notices.
The admin interface should expose detailed information about the status of a YP listing. As per #2167 a simp...There are hundreds if not thousands of streams that fail to list properly on dir.xiph.org and it's obvious that nobody notices.
The admin interface should expose detailed information about the status of a YP listing. As per #2167 a simplified status should be also exposed to the XML used for public status.
People don't read the error.log, ever, especially in this case.
We should expose:
* If the YP server accepted the initial touch
* If the server accepted the latest touch
* What was the last status message from the YP server for a failed touch
* What was the latest status message from the YP server, including successful
* Count of YP touches since source connection
* Count of failed YP touches since source connection
Rationale is, that there might be intermittent failures so we should expose both latest message and latest failure. Also latest message, if successful could contain some information like "server outdated and insecure, please update" or otherwise from the YP administration.
Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2192URL auth: override status code and send custom headers2018-09-28T15:04:52ZThomas B. RückerURL auth: override status code and send custom headersCurrently we're hardcoded to 401, if the backend refuses authentication. 403 might also be desireable or 30x with a _location_ header.
This needs two things:
* capability to set a custom status (including message)
* capability to send...Currently we're hardcoded to 401, if the backend refuses authentication. 403 might also be desireable or 30x with a _location_ header.
This needs two things:
* capability to set a custom status (including message)
* capability to send headers that will be forwarded to the client
The latter can also be used to set cookies, so is useful by itself.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2167Icecast should expose the YP listing status to the public status pages2018-06-16T22:44:16ZThomas B. RückerIcecast should expose the YP listing status to the public status pagesThere are hundreds if not thousands of streams that fail to list properly in dir.xiph.org and it's obvious that nobody notices.
/admin/stats should expose a per mount status field if the given mount is set public and directory listings ...There are hundreds if not thousands of streams that fail to list properly in dir.xiph.org and it's obvious that nobody notices.
/admin/stats should expose a per mount status field if the given mount is set public and directory listings are enabled for the server.
Logic could be as follows:
* *OK* - No known errors for this mount
* *WARN* - During the last n yp-touches at least one error was received
* *FAIL* - No successful listing/touch for this mount
Further information, including verbatim messages from YP should be available through the admin interface. Covered in a separate ticket.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2189Event triggers for Icecast 2.52019-01-22T06:35:22ZThomas B. RückerEvent triggers for Icecast 2.5We are introducing event triggers and need to decide what we trigger on. Currently already supported:
* source-connect
* source-disconnect
* icecast-start
* icecast-stop
Proposed additional triggers:
* client-connect (all connectio...We are introducing event triggers and need to decide what we trigger on. Currently already supported:
* source-connect
* source-disconnect
* icecast-start
* icecast-stop
Proposed additional triggers:
* client-connect (all connections that are !SOURCE|!PUT)
* client-disconnect (all connections that are !SOURCE|!PUT)
* icecast-reload (configuration reload as caused SIGHUP or web request)
* yp-failure
* metadata-change (Both in container and side-channel triggered, with differentiating field)
* various admin commands (Including authentication management)
* critical errors or even general logging (this needs to be thought through)Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2188Fowarding of headers to authentication system not working2019-06-26T17:17:19ZSebastianFowarding of headers to authentication system not workingHey everyone,
i tried to forward some cookies or other headers to my authentication sytem. Unfortunately this does not work. The doc says the headers would be part of a POST but they don't appear. Can anyone confirm that?
```
<...Hey everyone,
i tried to forward some cookies or other headers to my authentication sytem. Unfortunately this does not work. The doc says the headers would be part of a POST but they don't appear. Can anyone confirm that?
```
<option name="headers" value="x-pragma,x-token"/>
<option name="header_prefix" value="ClientHeader."/>
```
```
<mount>
<mount-name>/example.ogg</mount-name>
<authentication type="url">
<option name="mount_add" value="http://auth.example.org/stream_start.php"/>
<option name="mount_remove" value="http://auth.example.org/stream_end.php"/>
<option name="listener_add" value="http://auth.example.org/listener_joined.php"/>
<option name="listener_remove" value="http://auth.example.org/listener_left.php"/>
<option name="username" value="user"/>
<option name="password" value="pass"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
<option name="timelimit_header" value="icecast-auth-timelimit:"/>
<option name="headers" value="x-pragma,x-token"/>
<option name="header_prefix" value="ClientHeader."/>
<option name="stream_auth" value="http://auth.example.org/source.php"/>
</authentication>
</mount>
```
Best Regards
SebastianThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2158No metadata for the listenerer when sourcing with Mixxx on Windows2020-02-14T12:59:17ZSebastianNo metadata for the listenerer when sourcing with Mixxx on Windows2.4.99.1 aka 2.5 beta1 on windows with Mixxx as source client.
Unfortunately the metadata (title and artist) is not visible on iTunes anymore.
In 2.4.1 this was no problem. I tried to use the charset UTF-8 in Mixxx and in Icecast but i...2.4.99.1 aka 2.5 beta1 on windows with Mixxx as source client.
Unfortunately the metadata (title and artist) is not visible on iTunes anymore.
In 2.4.1 this was no problem. I tried to use the charset UTF-8 in Mixxx and in Icecast but it didn't work either.
Maybe someone could have a look at it.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2187implement event triggers 'client-connect' / 'client-disconnect' to match lega...2019-01-22T06:34:14ZThomas B. Rückerimplement event triggers 'client-connect' / 'client-disconnect' to match legacy url-auth```
<option name="listener_add" value="http://auth.example.org/listener_joined.php"/>
<option name="listener_remove" value="http://auth.example.org/listener_left.php"/>
```
should translate to triggers:
* 'client-connect'
* 'client-di...```
<option name="listener_add" value="http://auth.example.org/listener_joined.php"/>
<option name="listener_remove" value="http://auth.example.org/listener_left.php"/>
```
should translate to triggers:
* 'client-connect'
* 'client-disconnect'
Enables e.g. statistics collection without the potential problems of setting it up as auth.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2156Check feasibility of intro functionality for WebM2018-03-06T12:49:38ZThomas B. RückerCheck feasibility of intro functionality for WebMSee #2155 also #1941
We would need to see if an otherwise parameter compatible stream can be spliced seamlessly so that it doesn't cause players to complain/break.
If not feasible we should disable intro if content-type is WebM.See #2155 also #1941
We would need to see if an otherwise parameter compatible stream can be spliced seamlessly so that it doesn't cause players to complain/break.
If not feasible we should disable intro if content-type is WebM.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2183Adjust Icecast's Auth Realm2021-10-30T09:32:58ZMarvin ScholzAdjust Icecast's Auth RealmCurrently Icecast is using the following header for telling the server how to do auth:
`WWW-Authenticate: Basic realm="Icecast2 Server"`
The Auth realm name should probably adjusted to just one of the following:
- 'Icecast Server'
- '...Currently Icecast is using the following header for telling the server how to do auth:
`WWW-Authenticate: Basic realm="Icecast2 Server"`
The Auth realm name should probably adjusted to just one of the following:
- 'Icecast Server'
- 'Icecast 2 Server'
- 'Icecast Admin Interface'
- value of server name + ' Server'
(please leave a comment which one you would go for, even better if you have a good reason for it)Icecast 3.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2180SSL for admin only2020-10-15T09:24:19ZMelvyn SopacuaSSL for admin onlyHi,
I've tried the configuration below to setup SSL for the admn. This doesn't work and the documentation is too tierse to give me any hints.
Goal: Force and use SSL for /admin mountpoint. This needs to be a different URL (certificate ...Hi,
I've tried the configuration below to setup SSL for the admn. This doesn't work and the documentation is too tierse to give me any hints.
Goal: Force and use SSL for /admin mountpoint. This needs to be a different URL (certificate has limited hostnames)
Configuration tried:
```
<mount>
<mount-name>/admin</mount-name>
<ssl>1</ssl>
<stream-url>https://www.example.com:8000/admin</stream-url>
</mount>
```
Result:
1. Admin is accessible through HTTP
2. No secure connection can be established through HTTPS.
Note: firewall is not in play, because of 1), but verified regardless.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2155Improve WebM support in Icecast2019-06-26T17:23:33ZThomas B. RückerImprove WebM support in IcecastWe currently don't support the same use-cases as other formats.
This is partly due to the format - WebM doesn't support something like chaining.
We might work around a few things, but this needs to be explored.
This is a tracker ticket.We currently don't support the same use-cases as other formats.
This is partly due to the format - WebM doesn't support something like chaining.
We might work around a few things, but this needs to be explored.
This is a tracker ticket.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2175Url auth with HTTPS on Win not working2022-03-21T09:31:08ZSebastianUrl auth with HTTPS on Win not workingHi guys,
i tried url auth yesterday with an https link on windows.
I get this error here:
```
[2015-03-12 16:55:20] WARN auth_url/auth_url.c auth to server https://www.domain.com/auth.php failed with Problem with the SSL CA cert (pat...Hi guys,
i tried url auth yesterday with an https link on windows.
I get this error here:
```
[2015-03-12 16:55:20] WARN auth_url/auth_url.c auth to server https://www.domain.com/auth.php failed with Problem with the SSL CA cert (path? access rights?)
```
With this configuration:
```
<mount type="normal">
<mount-name>/radio</mount-name>
<max-listeners>10</max-listeners>
<username>...</username>
<password>...</password>
<authentication type="url">
<option name="listener_add" value="http://www.domain.com/auth.php"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
</authentication>
</mount>
```
I know that you have tried to make it run for windows. I just wanted to keep it tracked here.
Comments/ideas from tbr to that:
"it is working fine on linux. It might work on windows, but nobody figured out how to feed the CA path or file to the curl/nss combination."
"if someone figures out how OR if I switch to Fedora as the build distro, then it /might/ you're free to build on fedora, then it would link against an openssl curl and that might work, or not."
Thanks.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2150check if we need to forward port a possible win32 security fix from kh2020-10-15T11:20:19ZThomas B. Rückercheck if we need to forward port a possible win32 security fix from khhttps://github.com/karlheyes/icecast-kh/commit/b50c6374234154ad94b3c3a3e76545601e997739
```
do not use SO_REUSEADDR on windows, breaks the reload handling
MS defined SO_REUSEADDR differently to BSD and linux and have allowed some stupi...https://github.com/karlheyes/icecast-kh/commit/b50c6374234154ad94b3c3a3e76545601e997739
```
do not use SO_REUSEADDR on windows, breaks the reload handling
MS defined SO_REUSEADDR differently to BSD and linux and have allowed some stupid
security issue on it for port stealing. They messed it up, added another option
which doesn't help here and advise not using this option. Luckily the default
behaviour is acceptable. I've also avoided the abort case which should not trigger
but if it does, it reports an error and skips the rest.
```
Needs checking against Windows documentation. There might be some differences in how kh and we use things.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://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/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/2147Split up Icecast certificate handling into private and public key files2018-06-15T21:17:45ZThomas B. RückerSplit up Icecast certificate handling into private and public key filesThis would make it easier for people who are used to most software requiring two files, also it would make it easier to share certificate files with other server software like e.g. Apache httpd or dovecot imapd.This would make it easier for people who are used to most software requiring two files, also it would make it easier to share certificate files with other server software like e.g. Apache httpd or dovecot imapd.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2145Adding <outro> file for mountpoints2018-03-06T12:49:38ZJordan EricksonAdding <outro> file for mountpointsHello, I thought of the idea of adding an <outro> file for mountpoints. This would operate like <intro>, but the file would be played immediately after a source disconnects and before the <intro> of any fallback mounts that listeners are...Hello, I thought of the idea of adding an <outro> file for mountpoints. This would operate like <intro>, but the file would be played immediately after a source disconnects and before the <intro> of any fallback mounts that listeners are moved to. Thank you for your consideration =)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2111Race condition in fserv.c?2018-10-04T10:53:27ZMarvin ScholzRace condition in fserv.c?>race condition between avl_tree_unlock(pending_tree) and
>thread_cond_wait(&fserv_cond) in fserv.c, it's a pain to fix but should be.
Found in the TODO, still relevant?>race condition between avl_tree_unlock(pending_tree) and
>thread_cond_wait(&fserv_cond) in fserv.c, it's a pain to fix but should be.
Found in the TODO, still relevant?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2138VCLT support in current icecast is useless2018-03-06T12:49:38ZPhilipp SchafftVCLT support in current icecast is uselessIn current state VCLT support is in codebase but not exposed anywhere beside the admin interface. As of current state it is of no use as it is not exposed to the listeners in any way.
I request to
1. enable support by making it as visib...In current state VCLT support is in codebase but not exposed anywhere beside the admin interface. As of current state it is of no use as it is not exposed to the listeners in any way.
I request to
1. enable support by making it as visible as the other formats OR
1. disable it by removing the code to avoid any maintenance need in future releases.
dm8tbr acknowledged to take a decision on this before final release of 2.5.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2110Timer-based functionalities should use single timer thread2022-05-16T23:03:32ZMarvin ScholzTimer-based functionalities should use single timer thread>all timer-based functionality (yp updates, slave/relay checks) should have a
>single timer thread which dispatches events through the normal event
>mechanism (to worker threads from the main pool). This will reduce the
>extraneous threa...>all timer-based functionality (yp updates, slave/relay checks) should have a
>single timer thread which dispatches events through the normal event
>mechanism (to worker threads from the main pool). This will reduce the
>extraneous thread count.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2135Return "return" code for command_manageauth iceresponse2018-07-16T09:12:54ZMarvin ScholzReturn "return" code for command_manageauth iceresponseReturn "return" code in iceresponse for command_manageauth, to indicate if it failed or succeeded.Return "return" code in iceresponse for command_manageauth, to indicate if it failed or succeeded.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2109Abstract admin functionality to set of commands and handlers2020-10-15T09:20:39ZMarvin ScholzAbstract admin functionality to set of commands and handlers>abstract all admin functionality to a set of commands, and command handlers.
>
>Make /admin/* just parse according to a set of rules, and dispatch generic
>commands through that.
>
>Use this for alternative admin interfaces (GUI? telnet...>abstract all admin functionality to a set of commands, and command handlers.
>
>Make /admin/* just parse according to a set of rules, and dispatch generic
>commands through that.
>
>Use this for alternative admin interfaces (GUI? telnet interface?)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2134Please add SSL support for Master -> Slave relay connections2021-11-10T08:58:41ZJordan EricksonPlease add SSL support for Master -> Slave relay connectionsIn considering a secure end-to-end Icecast communication chain, it would be wonderful to have the ability for SSL enabled master -> slave relay connections.In considering a secure end-to-end Icecast communication chain, it would be wonderful to have the ability for SSL enabled master -> slave relay connections.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2108Registrable URL handlers in connection.c instead of hardcoded list2018-07-16T09:09:26ZMarvin ScholzRegistrable URL handlers in connection.c instead of hardcoded listSuggested in TODO
>general registerable url-handlers in connection.c rather than hard-coded list
>(already getting unmaintainable)Suggested in TODO
>general registerable url-handlers in connection.c rather than hard-coded list
>(already getting unmaintainable)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2130Add POST support to admin requests2018-10-04T10:42:35ZMarvin ScholzAdd POST support to admin requestsDue to how web stuff works and the web interface handles things (auth managements for instance) it is mandatory that we support POST, for properly sending data to the server.
(Just one downside of GET that already should be enough is th...Due to how web stuff works and the web interface handles things (auth managements for instance) it is mandatory that we support POST, for properly sending data to the server.
(Just one downside of GET that already should be enough is that the password would be in cleartext in the browser history)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2127Icecast needs a web-UI for configuration2018-03-06T12:49:38ZThomas B. RückerIcecast needs a web-UI for configurationThere are various existing projects, open and proprietary, but none really make full use of the potential, while being usable.
The Icecast project should have its own reference configuration UI. Either from scratch or by adopting an exis...There are various existing projects, open and proprietary, but none really make full use of the potential, while being usable.
The Icecast project should have its own reference configuration UI. Either from scratch or by adopting an existing open source project.
There are two possible approaches:
* Internal (somehow as part of /admin)
* External (running on a proper web server)
The former would make it self-contained, while the latter would enable us to leverage an existing framework.
Both approaches need to be explored before a decision is made.
PS: Being fairly self-contained this would be potentially a very good GSoC or similar project. I am also sufficiently familiar with the config file and live config mechanics to mentor such a task.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2107Provide a way for YP Dirs to check streams2020-10-15T11:58:06ZMarvin ScholzProvide a way for YP Dirs to check streams>directory server GUID checks
>
>directory server does GET /GUID-asldjfasldfjalsdkfjasldkfj HTTP/1.0
>and either gets a 404 if it's wrong, or a 200 if it's correct.
As suggested already in early drafts of the YP Protocol, there should b...>directory server GUID checks
>
>directory server does GET /GUID-asldjfasldfjalsdkfjasldkfj HTTP/1.0
>and either gets a 404 if it's wrong, or a 200 if it's correct.
As suggested already in early drafts of the YP Protocol, there should be a proper way to check if a stream is still reachable and running (and even maybe fetch updated metadata while at it).
This could be solved by implementing HTTP 1.1 HEAD and setting some headers, or as the TODO suggest, making a dedicated endpoint for it.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2126listener_remove is not triggered when kicking users2018-10-04T11:08:04ZMarius Flagelistener_remove is not triggered when kicking usersWhen kicking users, listener_remove isn't triggered. This has been tested on Icecast 2.3.3.
I haven't tested if this works if you remove a mount point, but one would like the same functionality here, that listener_remove is triggered as...When kicking users, listener_remove isn't triggered. This has been tested on Icecast 2.3.3.
I haven't tested if this works if you remove a mount point, but one would like the same functionality here, that listener_remove is triggered as well. I use these triggers to update a database with listeners and to make sure I have consistency, it would be nice if both triggers (listener_add and listener_remove) were triggered whatever causes a listener to be added and removed.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2070openSSL configuration overhaul in Icecast2023-01-03T10:26:01ZThomas B. RückeropenSSL configuration overhaul in IcecastI'd like to propose we update Icecast's openSSL configuration to have safer defaults and disable broken protocols and features completely.
Most recent vulnerabilities have been addressed by openSSL and should be up to date on people's sy...I'd like to propose we update Icecast's openSSL configuration to have safer defaults and disable broken protocols and features completely.
Most recent vulnerabilities have been addressed by openSSL and should be up to date on people's systems, but still we should do our part to prevent bad things from happening.
There will be dependent tickets filed for certain aspects.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2105Make config option (-c) optional?2018-06-16T22:40:36ZMarvin ScholzMake config option (-c) optional?> Should icecast automatically (i.e. without needing -c) look for the config file in /etc/icecast.xml or something?> Should icecast automatically (i.e. without needing -c) look for the config file in /etc/icecast.xml or something?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2119Filter based on User Agent2018-11-10T13:31:06ZPhilipp SchafftFilter based on User AgentThere is `<allow-ip>` and `<deny-ip>` already. Someone was asking me for a way to filter clients based on User Agents.
I would suggest to implement this as a role-type. This should allow matching on all headers and maybe on other kinds ...There is `<allow-ip>` and `<deny-ip>` already. Someone was asking me for a way to filter clients based on User Agents.
I would suggest to implement this as a role-type. This should allow matching on all headers and maybe on other kinds of client data as well.
The module would return `NOMATCH` on no match or `FAILED` on match on deny list. Behaviour on pass should maybe be documented. Defaulting to `NOMATCH` to continue with the processing of other `<role>`s.
Some technical background:
In contrast to the `<allow-ip>` and `<deny-ip>` this check can only happen after the client request has been parsed as it depends on data of exactly this client request. This makes it less suitable for (D)DoS protection in general. It should be considered to use some kind of firewalling of fail2ban to protect against such attacks.
Pros of implementing it the way described above:
- It would match the internal schemata and wouldn't be another alien.
- It could be extended to universally match any configured attributes of the client object.
- Integrates well into usage together with other `<role>`s. E.g. to allow some role access but deny others access depending on this module (admin can always go, listeners only if user agent matches).
- Rejects the client with a `401` according to the standard.
Contra:
- Is much slower than implementing it in a specific and specific way as it happens in the authentication engine and not in before on rejected clients. Slowdown for passing clients will not be significant.
- Rejects clients with a standard conforming `401`. Does not just drop them.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2061Investigate: Relay not recovering2021-10-30T09:42:21ZMarvin ScholzInvestigate: Relay not recoveringAs reported in IRC by AAA_awright, a relay doesn't seem to reconnect if the source mount times out, see attached log. This happened with Icecast 2.3.3, we should check that this does not happen with 2.4.0, it should recover if the source...As reported in IRC by AAA_awright, a relay doesn't seem to reconnect if the source mount times out, see attached log. This happened with Icecast 2.3.3, we should check that this does not happen with 2.4.0, it should recover if the source mountpoint is back.
> I had a problem where one of my relays has stopped relaying, and I couldn't bring it back up without a restart. It's only playing the fallback. It reloads the relay data from the master server, but ignores it somehow. It honors me changing the refresh interval in the config file and everything.
> The event seems to happen at 2014-10-12 05:41:13, and it never recovers or mentions the stream again
> If it helps, I don't see another "checking master stream list" for another 15 minutes: [2014-10-12 06:09:20] DBUG slave/_slave_thread checking master stream list
> Before 05:41, it occurs reliably every 120 secondsThomas 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/2117Creating a policy for removing support for obsoleted features/interfaces2018-06-16T22:40:11ZPhilipp SchafftCreating a policy for removing support for obsoleted features/interfacesThere needs to be a policy that tells when and how to remove a feature or interface that has been obsoleted for some reason. This policy will become very important when moving forward. Icecast recently had some major changes that move th...There needs to be a policy that tells when and how to remove a feature or interface that has been obsoleted for some reason. This policy will become very important when moving forward. Icecast recently had some major changes that move the internals away from how 2.3.2 was. Such a policy will help much to avoid keeping workarounds for older ways of doing stuff in the codebase and will be a major improvement to the code quality and maintainability.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2057Rewrite HTTP handling to correctly implement HTTP/1.12018-11-09T14:06:15ZMarvin ScholzRewrite HTTP handling to correctly implement HTTP/1.1Icecast should support HTTP/1.1 especially since we already do this partially for PUT support.
HEAD should probably be added too, since it might be useful and some players maybe do it to check content-type, length…
Additionally to compl...Icecast should support HTTP/1.1 especially since we already do this partially for PUT support.
HEAD should probably be added too, since it might be useful and some players maybe do it to check content-type, length…
Additionally to completely support PUT and stay in spec we need to support chunked encoding.Icecast 2.6Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2103Clarify default setting of logarchive2018-03-06T12:49:38ZMicheil SmithClarify default setting of logarchiveCurrently no default setting is in place for logarchive in the configuration, it's just by chance that the default is that it's off, due to how the internals of log.c work.Currently no default setting is in place for logarchive in the configuration, it's just by chance that the default is that it's off, due to how the internals of log.c work.Thomas 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/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/2101Verify if on-connect (events) are still impossible on windows2018-03-06T12:49:38ZThomas B. RückerVerify if on-connect (events) are still impossible on windowsWe migrated to mingw32, I suspect it might now be either trivial or easy to fork a script (.bat). We migrated to mingw32, I suspect it might now be either trivial or easy to fork a script (.bat). Icecast 2.6Stephan JauernickStephan Jauernickhttps://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/2024configure does not find speex when using non-standard prefix2018-10-17T14:49:29ZRoland Hermansconfigure does not find speex when using non-standard prefixI tried to compile icecast 2.4.0 using a non-standard prefix as follows:
```
./configure --prefix=<mydir>
```
The libraries libogg, libvorbis and libtheora are found, but libspeex is not:
```
checking for libogg... ok
checking for lib...I tried to compile icecast 2.4.0 using a non-standard prefix as follows:
```
./configure --prefix=<mydir>
```
The libraries libogg, libvorbis and libtheora are found, but libspeex is not:
```
checking for libogg... ok
checking for libvorbis... ok
checking for libtheora... ok
checking for libspeex... configure: WARNING: Speex support disabled!
```
The reason for this is that the configure script does not append SPEEX_CFLAGS to CPPFLAGS. Attached patch contains a fix for m4/speex.m4 that temporarily modifies CPPFLAGS in a way similar to the other libraries.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://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/2017out of band Opus Metadata updates not allowed2018-11-10T09:27:15Zkidxout of band Opus Metadata updates not allowedMessage: Mountpoint will not accept URL updates.
Return Code: 1Message: Mountpoint will not accept URL updates.
Return Code: 1Icecast 2.5.0Gitlab BotGitlab Bothttps://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ücker