Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-03-06T12:49:48Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1115Icecast+IE7+flash mp3 stream play2018-03-06T12:49:48ZbenpetiIcecast+IE7+flash mp3 stream playI'm not sure if it is true, maybe Icecast is already patched against it.
I read that I have to patch Icecast if I want to play the stream in flash, in IE7.
You can find the detailed description here:
www.jeroenwijering.com/?thread=Stream...I'm not sure if it is true, maybe Icecast is already patched against it.
I read that I have to patch Icecast if I want to play the stream in flash, in IE7.
You can find the detailed description here:
www.jeroenwijering.com/?thread=Streaming_IceCastMichael SmithMichael Smithhttps://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/1108icecast-2.3.1 fails to compile against curl-7.16.02018-03-06T12:49:48ZDanielicecast-2.3.1 fails to compile against curl-7.16.0Small bug report:
CURLOPT_PASSWDFUNCTION is a depreciated option ref:
curl.haxx.se/mail/lib-2003-10/0100.html
curl.haxx.se/mail/archive-2003-11/0001.html
They have finally removed it in curl-7.16.0.
Compile error as follows:
source='...Small bug report:
CURLOPT_PASSWDFUNCTION is a depreciated option ref:
curl.haxx.se/mail/lib-2003-10/0100.html
curl.haxx.se/mail/archive-2003-11/0001.html
They have finally removed it in curl-7.16.0.
Compile error as follows:
source='auth_url.c' object='auth_url.o' libtool=no \
depfile='.deps/auth_url.Po' tmpdepfile='.deps/auth_url.TPo' \
depmode=gcc3 /bin/sh ../depcomp \
i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -ffast-math -fsigned-char -I/usr/include/libxml2 -I/usr/include -pthread -march=athlon-xp -O2 -pipe -c
`test -f 'auth_url.c' || echo './'`auth_url.c
auth_url.c: In function `auth_get_url_auth':
auth_url.c:521: error: `CURLOPT_PASSWDFUNCTION' undeclared (first use in this
function)
auth_url.c:521: error: (Each undeclared identifier is reported only once
auth_url.c:521: error: for each function it appears in.)
make[3]: *** [auth_url.o] Error 1
make[3]: Leaving directory
`/var/tmp/portage/net-misc/icecast-2.3.1-r1/work/icecast-2.3.1/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/var/tmp/portage/net-misc/icecast-2.3.1-r1/work/icecast-2.3.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/net-misc/icecast-2.3.1-r1/work/icecast-2.3.1'
make: *** [all] Error 2
also reported here;
bugs.gentoo.org/show_bug.cgi?id=157756
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1951IceCast2 Mountpoint switchover buffer2018-03-06T12:49:48ZDarrenIceCast2 Mountpoint switchover bufferHi.
I've recently changed my SHOUTcast over to IceCast to stop any dead air and use mount points.
I have one little issue.
When the Auto DJ is connected, the music plays perfectly fine but when a source connects then that's when the ...Hi.
I've recently changed my SHOUTcast over to IceCast to stop any dead air and use mount points.
I have one little issue.
When the Auto DJ is connected, the music plays perfectly fine but when a source connects then that's when the stream starts to buffer, yet the listeners successfully transfer from the /autodj mount to the /live mount and vice versa when a source disconnects.
Now.. when listening via the Centova Cast player at the top, the stream doesn't buffer.. it only buffers when using flash players or any other player for that matter which are outside Centova Cast.
Do you know a way around this? Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2436Icecast2 server poll infinitly2022-04-12T11:55:18ZDorianNicolasIcecast2 server poll infinitlyHello,
I tried to start a icecast2 server with the command
`icecast2 -c test.xml`
Where test.xml is an unmodified configuration file of icecast2.
Here my logs when i start the command :
```
[2022-04-12 11:34:35] WARN CONFIG/_parse...Hello,
I tried to start a icecast2 server with the command
`icecast2 -c test.xml`
Where test.xml is an unmodified configuration file of icecast2.
Here my logs when i start the command :
```
[2022-04-12 11:34:35] WARN CONFIG/_parse_root Warning, <hostname> not configured, using default value "localhost". This will cause problems, e.g. with YP directory listings.
[2022-04-12 11:34:35] WARN CONFIG/_parse_root Warning, <location> not configured, using default value "Earth".
[2022-04-12 11:34:35] WARN CONFIG/_parse_root Warning, <admin> contact not configured, using default value "icemaster@localhost".
```
Only warnings and nothing happens. I can access the icecast2 page (localhost:3000), I can access admin page with logs and it works. But no mountpoint are printed even if I modified the list. The list is empty.
So I looked why the icecast2 server doesn't load mountpoints. And i found this with strace command :
```
read(7, "\2\232\337wPP|spA`\226\275'Z\20\33m\337\2XkW\352~\255\5\30$\232\360D"..., 52) = 52
close(7) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2960, ...}) = 0
write(5, "[2022-04-12 11:33:01] INFO conn"..., 101) = 101
poll([{fd=4, events=POLLIN}], 1, 300) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 300) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 300) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 300) = 0 (Timeout)
```
And nothing more, except this infinite message like if it were waiting something. I'm working on WSL2 (Ubuntu) on Windows. I tried on Windows the same steps in the same way but I have exactly the same for both, so I don't think the problem comes from Windows or WSL. Moreover, I can access to the Icecast2 link server and I can connect to the admin panel, but it doesn't load my mountpoints.
Any help would be appreciate,
Thankshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/567Icecast2 W32 Forms Client -> Windows Service2018-03-06T12:50:21ZjasonrIcecast2 W32 Forms Client -> Windows Service```
I think it makes sense to run the Icecast2 server as a Windows Service in this
environment as opposed to my current workaround as having it run as an alway
logged-in underprivilaged account under terminal services on Windows Server...```
I think it makes sense to run the Icecast2 server as a Windows Service in this
environment as opposed to my current workaround as having it run as an alway
logged-in underprivilaged account under terminal services on Windows Server
2003.
Same goes for ezstream, of course. =)
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2412Icescc process get down and do not restart itself sometimes2021-10-31T11:32:47ZcyberIcescc process get down and do not restart itself sometimes[strace.txt](/uploads/0b296196b41a9b62159085c24fd67e08/strace.txt)
[error.log.txt](/uploads/809f04a4b7eeef67d881d18ecf70d3e3/error.log.txt)
Hi,
This is the version we currently have:
icecast-2.4.2
I have launched a strace to the proces...[strace.txt](/uploads/0b296196b41a9b62159085c24fd67e08/strace.txt)
[error.log.txt](/uploads/809f04a4b7eeef67d881d18ecf70d3e3/error.log.txt)
Hi,
This is the version we currently have:
icecast-2.4.2
I have launched a strace to the process, I have attached the result to you.
Application process icescc for puntoblancobase is down and should be up; restarting: successful
And in error.log for the station we see this:
```
<04/26/21@17:42:56> [source] source dropped connection. disconnecting.
<04/26/21@17:43:57> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:44:27> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:44:57> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:45:27> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:45:57> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@17:45:59> [source] connected from 127.0.0.1
<04/26/21@17:45:59> [source] icy-name:XXXXXXXX ; icy-genre:Unspecified
<04/26/21@17:45:59> [source] icy-pub:0 ; icy-br:64 ; icy-url:http://www.xxxxxxxxxxx.es
<04/26/21@17:45:59> [source] icy-irc: ; icy-icq: ; icy-aim:
```
But in other stations icescc do not restart till we do from panel:
```
<04/26/21@15:00:36> [source] source dropped connection. disconnecting.
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:37> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:38> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:38> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@15:01:38> [dest: 95.211.135.97] server unavailable, disconnecting
```
.......
```
<04/26/21@16:22:16> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:16> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:17> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:17> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:17> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:17> [dest: 95.211.135.97] server unavailable, disconnecting
<04/26/21@16:22:24> [main] SIGTERM; exiting!
<04/26/21@16:22:29> [SHOUTcast] DNAS/Linux v1.9.8 (Feb 28 2007) starting up...
<04/26/21@16:22:29> [main] pid: 9099
<04/26/21@16:22:29> [main] loaded config from etc/server.conf
<04/26/21@16:22:29> [main] initializing (usermax:100 portbase:9122)...
<04/26/21@16:22:29> [main] No ban file found (etc/sc_serv.ban)
<04/26/21@16:22:29> [main] No rip file found (etc/sc_serv.rip)
<04/26/21@16:22:29> [main] opening source socket
<04/26/21@16:22:29> [main] source thread starting
<04/26/21@16:22:29> [main] opening client socket
<04/26/21@16:22:29> [main] Client Stream thread [0] starting
<04/26/21@16:22:29> [main] client main thread starting
<04/26/21@16:22:29> [source] listening for connection on port 9123
<04/26/21@16:22:33> [source] connected from 127.0.0.1
<04/26/21@16:22:33> [source] icy-name:XXXXXXXX ; icy-genre:Unspecified
<04/26/21@16:22:33> [source] icy-pub:0 ; icy-br:64 ; icy-url:http://www.xxxxxxxxx.es
<04/26/21@16:22:33> [source] icy-irc: ; icy-icq: ; icy-aim:
```
Could you tell us which could be the cause for this problem? And how to solve it?
Product name:
Centova Cast v3https://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/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/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/2010Improve Icecast htpasswd hash storage security2023-02-21T23:42:29ZThomas B. RückerImprove Icecast htpasswd hash storage securityCurrently Icecast uses unsalted md5 hashes of passwords.
Once an attacker obtains access to those the risk is high that simple passwords will be broken by simple md5 look-up through web search.
We should move to using bcrypt, as it's li...Currently Icecast uses unsalted md5 hashes of passwords.
Once an attacker obtains access to those the risk is high that simple passwords will be broken by simple md5 look-up through web search.
We should move to using bcrypt, as it's license permits us to incorporate it, also it should allow us to be compatible with the standard htpasswd(1) manipulation tool.
In the meanwhile using forwarded http authentication potentially offers higher security by deferring authentication to another http server.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2358Improve Icecast's logging of developer only messages2019-04-23T13:54:32ZPhilipp SchafftImprove Icecast's logging of developer only messagesCurrently Icecast logs many details that are only of interest to developers. Those lines "spam" the error log.
There should be a way to disable those messages. This could happen using the well-known DEBUG macro OR by adding another log ...Currently Icecast logs many details that are only of interest to developers. Those lines "spam" the error log.
There should be a way to disable those messages. This could happen using the well-known DEBUG macro OR by adding another log level or log flag (as those messages may themself have different log levels as per their logic).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2354Improve way of what URI is sent to YP2022-03-21T23:14:53ZPhilipp SchafftImprove way of what URI is sent to YPAt this point the URI sent to YP servers is based on the hostname and global port setting. However this does not work with TLS enabled and may not work for more complex setups with internal-/external-split (including different hostnames)...At this point the URI sent to YP servers is based on the hostname and global port setting. However this does not work with TLS enabled and may not work for more complex setups with internal-/external-split (including different hostnames).
An attribute to the `<directory>` tag should be added that takes the ID of a `<listen-socket>` on which behalf the YP submission should be made. That `<listen-socket>` may be `type="virtual"`.
See: #2171Marvin ScholzMarvin Scholzhttps://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/2097In <listener> in some tags are camelcase that should be converted to lowercase.2018-03-06T12:49:47ZPhilipp SchafftIn <listener> in some tags are camelcase that should be converted to lowercase.in <listener> the following tags are camelcase: <ID>, <IP>, <UserAgent> and <Connected>. Those should be converted to lower case.
XML tells that tag names are case sensitive.
This needs to be documented before we can change it and be cha...in <listener> the following tags are camelcase: <ID>, <IP>, <UserAgent> and <Connected>. Those should be converted to lower case.
XML tells that tag names are case sensitive.
This needs to be documented before we can change it and be changed with a major release. I suggest to document it as 'Parsers MUST be case insensitive for ALL tags in ANY admin/-command output.'
```
09:51 <+tbr> as a broad statement, I'd not expect this change to happen before 2.6
09:52 < ph3-der-loewe> I haven't thought about a timeline for that already.
09:52 < ph3-der-loewe> I'm fine with <= 3.0.0 :)
09:53 < ph3-der-loewe> with 3.0.0 the question that arise is if the interface still exist ;)
```
Please review this before 2.5 to check if we are on-track on this.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2394Include libshout release 2.4.4 on website2020-10-02T20:20:37ZPhilipp SchafftInclude libshout release 2.4.4 on websiteThe following libshout release should distributed on the mirrors and then included in the website:
```
ddc44d4db0193471b1a61d41e8ec975a021da4f5af657716ecbb1eaf95231e03ac44036148f0d5bd897ba5c03f075fd67017fecfccebb4f11be56375c0e5c088 lib...The following libshout release should distributed on the mirrors and then included in the website:
```
ddc44d4db0193471b1a61d41e8ec975a021da4f5af657716ecbb1eaf95231e03ac44036148f0d5bd897ba5c03f075fd67017fecfccebb4f11be56375c0e5c088 libshout-2.4.4.tar.gz
7273d5e8da3ad10e6fc754663df5b56e8058a41f libshout-2.4.4.tar.gz
```Ralph GilesRalph Gileshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/632Incorrect Base64 decoder in utils (missing '2018-03-06T12:50:22ZGitlab BotIncorrect Base64 decoder in utils (missing '*Base64 utils. Encode is ok, but decode? '=' is missed, so, VLC, that
contains correct base64 encoder, produces '=' at the end of the string.
We need to pacth that case in decoder:
char *util_base64_decode(unsigned char *input)
{
...*Base64 utils. Encode is ok, but decode? '=' is missed, so, VLC, that
contains correct base64 encoder, produces '=' at the end of the string.
We need to pacth that case in decoder:
char *util_base64_decode(unsigned char *input)
{
int len = strlen(input);
char *out = malloc(len*3/4 + 5);
char *result = out;
signed char vals[4];
while(len > 0) {
if(len < 4 && *input != '=')
{
free(result);
return NULL; /* Invalid Base64 data */
} else if (*input == '=') break;
Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1323Incorrect build instructions in icecast README2018-03-06T12:49:48ZMonty MontgomeryIncorrect build instructions in icecast README...don't forget to update the Icecast README to reflect proper build instruction now that it's automake'd. It's confused a few users this week....don't forget to update the Icecast README to reflect proper build instruction now that it's automake'd. It's confused a few users this week.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1131incorrect display when there are chinese characters2018-03-06T12:49:48Zgonwanincorrect display when there are chinese charactersWhen the stream title, description and artist contains Chinese characters, icecast will display incorrectly. It seems these strings are truncated by wrong length. When the stream title, description and artist contains Chinese characters, icecast will display incorrectly. It seems these strings are truncated by wrong length. Icecast 2.3Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/913incorrect mime-type for AAC files on Windows2018-03-06T12:49:49Zharreldincorrect mime-type for AAC files on WindowsIcecast on Windows sends the wrong mime-type to a client for AAC-files.
It is sending "application/octet-stream" in stead of "audio/aac" or "audio/aacp".
this occurs only with files, live streams encoded by an AAC(+) encoder is being han...Icecast on Windows sends the wrong mime-type to a client for AAC-files.
It is sending "application/octet-stream" in stead of "audio/aac" or "audio/aacp".
this occurs only with files, live streams encoded by an AAC(+) encoder is being handled correctly.
The reason for this is probably that icecast searches for mime-types on the wrong place.
The result is that players that expect the audio/aac(p) mime-type for AAC-files, do not play AAC-files served by icecast.Icecast 2.3Michael SmithMichael Smith