Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2020-02-14T13:26:12Zhttps://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/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/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/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/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/1959Icecast to accept custom REMOTE IP headers for reverse proxy compatibility.2022-11-10T18:58:16ZYahavIcecast to accept custom REMOTE IP headers for reverse proxy compatibility.Would be nice to be able to set a custom header name in the config in which Icecast will check for the remote ip address.
(<IP-HEADER>X-Forwarded-For</IP-HEADER>)
will be useful with reverse proxying and such.
(Implemented in KH-2.3.3-kh...Would be nice to be able to set a custom header name in the config in which Icecast will check for the remote ip address.
(<IP-HEADER>X-Forwarded-For</IP-HEADER>)
will be useful with reverse proxying and such.
(Implemented in KH-2.3.3-kh1: http://karlheyes.github.io ) Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1860[PATCH] Send credentials when doing master-relay2018-11-10T13:05:22Zcato[PATCH] Send credentials when doing master-relayWhen using a configuration with a hidden master and some relays using master-relay it should be possible to enable password protection on streams in the master icecast. Therefore it is necessary for the relaying-icecast to send credentia...When using a configuration with a hidden master and some relays using master-relay it should be possible to enable password protection on streams in the master icecast. Therefore it is necessary for the relaying-icecast to send credentials to the master-icecast. The natural choice would be to send the `<master-username>` and `<master-password>`.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2365Discussion on the handling of portless Host:-headers2020-10-11T15:59:37ZPhilipp SchafftDiscussion on the handling of portless Host:-headersKarl updated Icecast in 64d2fc1faa46cf98b0576521c4975d3ae43ff252 to ignore Host:-headers that do not include a port. This was done due to the fact that winamp and foobar2000 do send invalid Host:-headers. They do not include the port eve...Karl updated Icecast in 64d2fc1faa46cf98b0576521c4975d3ae43ff252 to ignore Host:-headers that do not include a port. This was done due to the fact that winamp and foobar2000 do send invalid Host:-headers. They do not include the port even if non-default ports are used. When this header is used this results in invalid playlists to be generated. (Other (future) uses such as vhosting may also be affected).
foobar2000 seems to have fixed this. This was the result of a quick test with @laama. Thanks to him.
Winamp 5.53 1898 Beta from 2008 as well as Winamp 5.8 as downloaded today are still affected.
The following solution and workarounds come to mind:
* Nullsoft fixes their software. (Judge yourself if this is going to happen.) This is the only solution. It is the only correct way to do this.
* Keep ignoring Host:-headers that do not include a port. This may break legitimate clients.
* Try to match Host:-headers against listen sockets. This may break vhosting.
* Implement a way to list valid vhosts and set default vhosts per listen socket.
* Ignore Host:-headers without a port but implement a per listen socket default vhost setting.
Note that we can not accept/reject Host:-headers without port based on if we listen on a default port socket or not without type="virtual" listen sockets. This will otherwise break all kinds of redirects.
This ticket is mostly for discussion.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2375Cross-Origin Preflight OPTIONS sends 4012023-03-06T15:12:48ZBradley HiltonCross-Origin Preflight OPTIONS sends 401When a browser does a cross-origin request with preflight, icecast server fails with `401 Authentication Required` when there is no way to include the user credentials.
https://www.w3.org/TR/cors/#preflight-requestWhen a browser does a cross-origin request with preflight, icecast server fails with `401 Authentication Required` when there is no way to include the user credentials.
https://www.w3.org/TR/cors/#preflight-requesthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2383Oversized EBML headers for WebM live stream2022-03-09T19:32:39ZWolne WilnoOversized EBML headers for WebM live streamFrom version ffmpeg 4.1 or above, when trying to stream WebM video Icecast produce error: `EBML Header too large, failing`
Solution is to increase EBML Header in `format_ebml.c` from 131072 bytes (0.125 MiB) to bytes 524288 (0.5 Mib)
C...From version ffmpeg 4.1 or above, when trying to stream WebM video Icecast produce error: `EBML Header too large, failing`
Solution is to increase EBML Header in `format_ebml.c` from 131072 bytes (0.125 MiB) to bytes 524288 (0.5 Mib)
Change in https://gitlab.xiph.org/xiph/icecast-server/-/blob/master/src/format_ebml.c from `#define EBML_HEADER_MAX_SIZE 131072` to `#define EBML_HEADER_MAX_SIZE 524288`https://gitlab.xiph.org/xiph/icecast-server/-/issues/2387listclients not working if authentication type is url2020-10-15T10:35:27Znaitsirchlistclients not working if authentication type is urlWe have configured our Icecast (v. 2.4.4) mount with stream_auth via URL. Authentication with the source client works well. But it is comming to a strange error when listener stats are requested with the source password.
This is our mou...We have configured our Icecast (v. 2.4.4) mount with stream_auth via URL. Authentication with the source client works well. But it is comming to a strange error when listener stats are requested with the source password.
This is our mount config:
```xml
<mount type="default">
<mount-name>/stream</mount-name>
<stream-name><![CDATA[Test]]></stream-name>
<authentication type="url">
<option name="auth_header" value="icecast-auth-user: 1"/>
<option name="stream_auth" value="https://my-authentication-provider.com/api/icecast/stream_auth"/>
</authentication>
</mount>
```
Streaming with butt and source password works as expected. So the authentication works.
Now, if I try to access the URL `/admin/listclients?mount=/stream` with the source password, to see the number of connected listeners. I get a *403 Forbidden* with the message `Mountpoint in use`.
This is the request that is sent by curl:
```
GET /admin/listclients?mount=/stream HTTP/1.1
Host: server34299.streamplus.de:10106
Authorization: Basic {...}
User-Agent: curl/7.64.0
Accept: */*
```
I have checked the base64 encoded username and password in the authentication header. It is the same that is used in the source client.
The response by Icecast is:
```
HTTP/1.0 403 Forbidden
Server: Icecast 2.4.4
Connection: Close
Date: Wed, 17 Jun 2020 11:58:06 GMT
Content-Type: text/plain; charset=utf-8
Cache-Control: no-cache, no-store
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Pragma: no-cache
Mountpoint in use
```
If I remove the `<authentication type="url">` part of the config and restart the server, calling `/admin/listclients?mount=/stream` works as expected.
It looks like the listclients action has a bug if Icecast is running with stream_auth via URL. If you need any further information please let me know.
OS: Debian 10.4, Linux version 4.19.0-9-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07)
**Update:**
If I use the admin credentials to access the listener stats, it works as expected.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2391Found memory leak problems on ubuntu 20.04 tls2024-01-21T02:16:55ZChaichanaFound memory leak problems on ubuntu 20.04 tlsubuntu 20.04tls icecast2 use abnormal memory, unlike ubuntu 18.04 that doesn't use memory much
Must use the command service icecast2 restart memory to return to normal But before long, it will be leak same.
- Installation of all applica...ubuntu 20.04tls icecast2 use abnormal memory, unlike ubuntu 18.04 that doesn't use memory much
Must use the command service icecast2 restart memory to return to normal But before long, it will be leak same.
- Installation of all applications
https://mediarealm.com.au/articles/icecast-https-ssl-setup-lets-encrypt/
- IMAGE
Top in image ubuntu 18.04 tls
Bottom in image ubuntu 20.04 tls
![ฟ](/uploads/d236d04fa7fc56f7c97c7d47e7937a12/ฟ.jpg)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2410URL auth does not work with HTTP/2 servers2023-01-03T10:21:48ZMarvin ScholzURL auth does not work with HTTP/2 serversUsing URL auth with a HTTP/2 capable sever does not work properly:
```text
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "HTTP/2 200 .."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "...Using URL auth with a HTTP/2 capable sever does not work properly:
```text
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "HTTP/2 200 .."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "date: Sun, 25 Apr 2021 11:40:34 GMT.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "server: Apache.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "x-icecast-auth-result: ok.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "x-icecast-auth-alter-action: redirect_permanent.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "x-icecast-auth-alter-argument: https://stream.example.com/hits/highquality.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "content-type: application/json.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: ".."
[2021-04-25 13:40:34] EROR auth_url/handle_returned_header__complete Can not parse auth backend reply.
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2417After working days without problem Icecast 2.4.4 not trying to update relays ...2022-02-19T09:59:17ZdanielsoheilAfter working days without problem Icecast 2.4.4 not trying to update relays from master serverthis my icecast.xml config:
```
<icecast>
<location>Iran</location>
<admin>info@myts3.ir</admin>
<limits>
<clients>50000</clients>
<sources>1000</sources>
<queue-size>307200</queue-size>
<...this my icecast.xml config:
```
<icecast>
<location>Iran</location>
<admin>info@myts3.ir</admin>
<limits>
<clients>50000</clients>
<sources>1000</sources>
<queue-size>307200</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>600</header-timeout>
<source-timeout>600</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>196608</burst-size>
</limits>
<authentication>
<source-password>removed</source-password>
<relay-password>removed</relay-password>
<admin-user>admin</admin-user>
<admin-password>removed</admin-password>
</authentication>
<hostname>radio.myts3.ir</hostname>
<listen-socket>
<port>18000</port>
</listen-socket>
<http-headers>
<header name="Access-Control-Allow-Origin" value="*" />
</http-headers>
<master-server>192.168.100.53</master-server>
<master-server-port>8000</master-server-port>
<master-update-interval>30</master-update-interval>
<master-password>removed</master-password>
<relays-on-demand>0</relays-on-demand>
<fileserve>1</fileserve>
<paths>
<basedir>/usr/share/icecast</basedir>
<logdir>/var/log/icecast</logdir>
<webroot>/usr/share/icecast/web</webroot>
<adminroot>/usr/share/icecast/admin</adminroot>
<alias source="/" destination="/status-json.xsl"/>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<loglevel>4</loglevel>
<logsize>100000</logsize>
</logging>
<security>
<chroot>0</chroot>
</security>
</icecast>
```
i have logs too, its 66mB i can't send it here.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2422Programmatically set the fallback-override value2021-10-31T22:11:44Zisaac-codeProgrammatically set the fallback-override valueAs advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fall...As advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fallback, but immediately the mountpoint is back, I cannot programmatically switch back to the mountpoint
Switching back to the former mountpoint is only possible when the fallback-override value is set to 1, but I cannot achieve that because there is no way to programmatically achieve that, which is weird.
P.S. I want users to create mountpoints via an exposed endpoint, so I don't create it manually inside the icecase.xml filehttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2437Provide systemd services (replace sysv scripts)2022-04-22T10:03:14ZJonas L.Provide systemd services (replace sysv scripts)Could you provide a systemd service and start replacing the old sysv scripts ?
A lot of distribution provided there own service files, but I was hoping to move those service files upstream.
- https://github.com/archlinux/svntogit-commu...Could you provide a systemd service and start replacing the old sysv scripts ?
A lot of distribution provided there own service files, but I was hoping to move those service files upstream.
- https://github.com/archlinux/svntogit-community/blob/5c80c74e8011a5f5ff31a4fff4769c96c7f07182/trunk/icecast.service
- https://src.fedoraproject.org/rpms/icecast/blob/rawhide/f/icecast.service
- Debian still relies on the sysv script, and I was hoping that once the service file is here, it would trickle down to Debian.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2438Segfault when public is "True"2022-11-09T10:21:58ZAlexey ParamonovSegfault when public is "True"[icecast_3.conf](/uploads/6b3b69fb7077a4dc5364951670846a74/icecast_3.conf)
Icecast 2.5 (Icecast 2.4.99.3) dies with a segfault if there are the following lines in the config file:
```
<public>1</public>
<stream-name>Click Yo...[icecast_3.conf](/uploads/6b3b69fb7077a4dc5364951670846a74/icecast_3.conf)
Icecast 2.5 (Icecast 2.4.99.3) dies with a segfault if there are the following lines in the config file:
```
<public>1</public>
<stream-name>Click Your Radio Dutch</stream-name>
<stream-description>The best in Dutch Music and Comedy</stream-description>
<stream-url>www.clickyourradio.com</stream-url>
<genre>Music &amp; Comedy</genre>
```
Complete config file is attachedPhilipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2439HTTP request EOF problem2022-05-07T15:37:59ZCsaba27HTTP request EOF problemHello, i have a problem with icecast 2.4.99 version, after the http response the icecast doesn't close the connection.
There is an example code from PHP:
```
<?php
// ini_set("default_socket_timeout", 5);
$start = microtime(true);
$...Hello, i have a problem with icecast 2.4.99 version, after the http response the icecast doesn't close the connection.
There is an example code from PHP:
```
<?php
// ini_set("default_socket_timeout", 5);
$start = microtime(true);
$fp = fsockopen("icecast-example-host.com", 8000, $errno, $errstr, 5);
if ($fp)
{
$out = "GET /status_json.xsl HTTP/1.1\r\n";
$out .= "Connection: Close\r\n";
$out .= "Host: icecast-example-host.com:8000\r\n";
$out .= "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36\r\n";
$out .= "\r\n";
fwrite($fp, $out);
// stream_set_timeout($fp, 5);
$line_count = 0;
while (!feof($fp))
{
$line_count++;
echo $line_count . " " . fgets($fp);
# echo fread($fp, 1024);
}
fclose($fp);
}
else
{
echo $errstr . " (" . $errno . ")" . PHP_EOL;
}
echo PHP_EOL . " " . round(microtime(true) - $start, 4);
```
Run in console and check the execution time (request time).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2451a potential bug of NPD2022-09-14T08:41:54Zash1852a potential bug of NPDHi, I found a potential null pointer dereference bug in the project source code of libshout, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that gen...Hi, I found a potential null pointer dereference bug in the project source code of libshout, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug,the file path can be seen in the blue framed section.
![getvar](/uploads/8fc4ca569f4f83b6f01a8c2ea5e57342/getvar.jpg)
what i am confused about is, there are some code snippets can be found in project that checking if return value of httpp_getvar equal to null, maybe the context in which the code snippet is located can asserts that the return value cannot be equal to null? but I haven't found such code can assert this.
Although the code shown is for the latest but is still exist in current version.would you help to check if this bug is true?thank you for your patience and effort!Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2458IPv6 support?2023-01-03T15:46:45ZFabien SchenkelsIPv6 support?Hi,
It seems that Icecast does not work in IPv6?
I can't bind an IPv6 address, I get this error: `EROR connection/connection.c Could not create listener socket on port 8000 bind 2a0a:xxx`
```
<listen-socket>
<port>8000</port>
<bind...Hi,
It seems that Icecast does not work in IPv6?
I can't bind an IPv6 address, I get this error: `EROR connection/connection.c Could not create listener socket on port 8000 bind 2a0a:xxx`
```
<listen-socket>
<port>8000</port>
<bind-address>2a0a:xxxxx</bind-address>
</listen-socket>
```
thanks for your feedbackMarvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2462Track's end is repeated2023-11-18T23:34:29ZDan SanfordTrack's end is repeatedI have
- opus files
- ices2 2.0.3-1
- icecast2 2.4.4-4
- on debian
The problem is that it repeats end of tracks a 2nd time. (happens many times, even on fresh boot, but not always)
The repeat length looks close to buffer size, so that'...I have
- opus files
- ices2 2.0.3-1
- icecast2 2.4.4-4
- on debian
The problem is that it repeats end of tracks a 2nd time. (happens many times, even on fresh boot, but not always)
The repeat length looks close to buffer size, so that's why I think it's in icecast2.
I have downloaded the played opus file, and its end is played correctly offline. So that rules out my files.
I have never noticed this repeat on official radio streams with my player. So that rules out my player.
I have noticed it on 2 separate client PCs, so that points to the server.
I've tuned my /etc/icecast2/icecast.xml so there are no dropouts:
```
<limits>
<clients>100</clients>
<sources>20</sources>
<queue-size>1048576</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>262140</burst-size>
</limits>
```
ices2 doesn't have a forum to ask the same question.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2469HLS (HTTP Live Streaming) should be supported2023-11-28T18:36:05ZBjoern JackeHLS (HTTP Live Streaming) should be supportedplain http audio streams as Icecast supportes them currently have two major drawbacks for clients:
1) network connectivity changes lead to audio stream losses, clients will have to reconnect, audio will be interrupted
2) network modems...plain http audio streams as Icecast supportes them currently have two major drawbacks for clients:
1) network connectivity changes lead to audio stream losses, clients will have to reconnect, audio will be interrupted
2) network modems have to be busy continously because the plain audio stream is being sent all the time. The permanent activity of the modem is not energy efficient at all. Mobile devices suffer from noticable battery drain.
The solution to the above mentioned problems is HLS (https://en.wikipedia.org/wiki/HTTP_Live_Streaming). The Rocket Streaming Audio Server from https://rocketbroadcaster.com/streaming-audio-server/ does support HLS for example.
With HLS audio streams modems of client devices can stay idle most of the time, as a result of that you see greatly enhanced battery live - and network switching and even short network outages will not be a problem for clients any more.
It would be awesome if Icecast would add support for HLS, too, to overcome the shortcomings of plain audio streams, which especially mobile users suffer from considerably.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2472Locking issue with logging2024-01-14T14:15:37ZPhilipp SchafftLocking issue with loggingCurrently the signal handlers as well as the event subsystem's exec backend logs messages. Those seem to be subject to restrictions on the logging code's locking. This can result in the process hanging. It is unclear whether or not this ...Currently the signal handlers as well as the event subsystem's exec backend logs messages. Those seem to be subject to restrictions on the logging code's locking. This can result in the process hanging. It is unclear whether or not this may also corrupt the process in any way.
See also (likely unrelated): #2231