Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2023-04-06T12:41:42Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2457add MPTCP support2023-04-06T12:41:42ZBjoern Jackeadd MPTCP supportMPTCP allows clients to switch from one network to another network without the TCP connection to break. So a client can be in a WIFI network and move to a LAN or a mobile data connection and the TCP connection stays alive. This is ideal ...MPTCP allows clients to switch from one network to another network without the TCP connection to break. So a client can be in a WIFI network and move to a LAN or a mobile data connection and the TCP connection stays alive. This is ideal for streaming applications and this would be perfect for Icecast. MPTCP v1 support was added to the Linux kernel in the early 5.x releases. Adding support for it for server applications is simple. MPTCP support is also transparent for non-MPTCP-aware devices.
All that being said, please add support for MPTCP to Icecast and have it enable it by default.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2452status-json.xsl not working (Issue #55 on github)2022-11-09T14:05:17ZKlaus Kobaldstatus-json.xsl not working (Issue #55 on github)thanks for the answer:
> status-json.xsl is deprecated. What is not deprecated is all below /admin/ (the actual API). Plus for 2.5.x there is a new /admin/publicstats endpoint that is kind-of the successor of status-json.xsl.
>
> status...thanks for the answer:
> status-json.xsl is deprecated. What is not deprecated is all below /admin/ (the actual API). Plus for 2.5.x there is a new /admin/publicstats endpoint that is kind-of the successor of status-json.xsl.
>
> status-json.xsl is an optional part (meaning it is installed by default but operators sometimes choose to remove it). While being deprecated it is still provided at this point. If your installation lacks it it's most likely because someone removed it (which might or might not have a reason). You can however you reinstall it by copying the latest versions of status-json.xsl, and xml2json.xslt (both located in /web/).
I tried
localhost:8000/admin/publicstats
produces:
400 - Unrecognised command
I am using this docker container:
moul/icecast:latest
Is there a better ready container maybe?https://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/2450a potential bug of NPD2022-09-06T00:08:21Zash1852a potential bug of NPDHi, I found a potential null pointer dereference bug in the project source code of icecast-Server, 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 th...Hi, I found a potential null pointer dereference bug in the project source code of icecast-Server, 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 red arrows represent the control flow,the file path can be seen in the blue framed section.
![image](/uploads/92074055051bc53bda3046f7bc09838d/image.png)
Although the code shown is for the latest but is still exist in current version. (https://gitlab.xiph.org/xiph/icecast-server/-/blob/master/src/format_ogg.c#L452-L454)
would you can help to check if this bug is true?thank you for your effort and patience!Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2445Finished streams are still shown as online and aren't cleared up by Icecast -...2022-11-12T17:15:38ZMole ManFinished streams are still shown as online and aren't cleared up by Icecast - have to kill the source to free up the mountpointHi guys,
I noticed that occasionally streamers end their stream but their stream is still shown as live on the server status page, you can't connect to the stream as a listener (VLC tries to connect forever) and the stream doesn't get ...Hi guys,
I noticed that occasionally streamers end their stream but their stream is still shown as live on the server status page, you can't connect to the stream as a listener (VLC tries to connect forever) and the stream doesn't get removed by Icecast after any period of time, so I have to kill the source in the admin UI to get rid of it. The source timeout in the limits section of the icecast.xml is set to 10 seconds. In the admin UI I can also see that no packets are transferred (params total_bytes_read and total_bytes_sent don't change), so Icecast should be able to see that the stream is inactive. This has happened to at least two different users/mountpoints and it happened twice this week to the same user, but it only happens sometimes. This does not seem to affect other mountpoints, other users can still start and stop streams while the zombie stream is on.
I also think that this only started to happen in the last few months, but the only change I implemented in that timespan was the addition of an SSL certificate and a mountpoint which uses SSL. The stream in the example wasn't encrypted though, so I don't think these things are related. I attached screenshots of the stuck stream in the admin console and of the access.log where the timestamps look suspicious to me, the message of the stream start looks like it was only logged when I killed the source the next day - though I might have misunderstood that part :-) better have a look for yourself, see the screenshot for more details. There was no heavy load or any other unusual events while this happened.
Impact: This leads to users not being able to reconnect to their own mountpoint in case they get disconnected until an admin manually kills the source.
Otherwise: Great software, runs smooth with minial administration overhead. Thanks in advance for checking!
Environment: Icecast 2.4.4 running on a VPS with CentOS 7
Limits:
<limits>
<clients>400</clients>
<sources>20</sources>
<threadpool>5</threadpool>
<queue-size>524288</queue-size>
<client-timeout>20</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>0</burst-on-connect>
<burst-size>65535</burst-size>
</limits>https://gitlab.xiph.org/xiph/icecast-server/-/issues/2444Setup pre-commit config2022-07-04T12:31:56ZJonas L.Setup pre-commit configI propose to add a https://pre-commit.com/ config to this repository to add code formatting/cleaning and few checks to keep the files in check.
Here is a config draft I propose:
```yml
---
# See https://pre-commit.com for more informati...I propose to add a https://pre-commit.com/ config to this repository to add code formatting/cleaning and few checks to keep the files in check.
Here is a config draft I propose:
```yml
---
# See https://pre-commit.com for more information
# See https://pre-commit.com/hooks.html for more hooks
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.3.0
hooks:
- id: check-added-large-files
- id: check-case-conflict
- id: check-executables-have-shebangs
- id: check-shebang-scripts-are-executable
- id: check-symlinks
- id: destroyed-symlinks
- id: check-json
- id: check-yaml
- id: check-xml
- id: check-merge-conflict
- id: end-of-file-fixer
- id: mixed-line-ending
- id: trailing-whitespace
- repo: https://github.com/pre-commit/mirrors-prettier
rev: v2.6.2
hooks:
- id: prettier
files: \.(md|yml|yaml)$
- repo: https://github.com/codespell-project/codespell
rev: v2.1.0
hooks:
- id: codespell
args:
- --builtin=clear,rare,informal
```
This would also mean to add a CI job to enforce those checks.
Personally it would make it easier for me to edit files using a IDE that automatically format and clean on save (which I consider a good practice), and prevent some spelling error to land in the code.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2442CPU churning by Body and Request Queue thread2022-11-15T12:22:44ZLászló KárolyiCPU churning by Body and Request Queue threadas discussed on IRC, here's the long awaited 'official bug report' about 2.5 beta.
Whenever I run it on a server that can at times serve 1000 clients, after restart the thread name "Request Queue" starts consuming 100% CPU instantly. Af...as discussed on IRC, here's the long awaited 'official bug report' about 2.5 beta.
Whenever I run it on a server that can at times serve 1000 clients, after restart the thread name "Request Queue" starts consuming 100% CPU instantly. After a while, "Body Queue" does the same.
This ends up in a 2.2 load (15 min average) on a 4 CPU server.
The server is a standard Ubuntu (20.04.4 LTS), nothing extra added, using UFW.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2441Icecast 2.5 beta 3 stops after 3 seconds2023-01-03T10:08:01ZMichelIcecast 2.5 beta 3 stops after 3 secondsThe ssl/https output stops after 3 seconds. The http output is okay. I have already report this on 2.4.
I use Debian 10 for OS.
Best regards,
MichelThe ssl/https output stops after 3 seconds. The http output is okay. I have already report this on 2.4.
I use Debian 10 for OS.
Best regards,
Michelhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/24402.5 Beta not adhering to master-update-interval2022-05-17T19:14:44ZUmar Dockrat2.5 Beta not adhering to master-update-intervalGood Day,
I've set master-update-interval to every 5 seconds however based on the observered stream sync behaviour and relay server log messages:
```
[2022-05-15 22:52:39] INFO slave/update_from_master Master accepted streamlist reque...Good Day,
I've set master-update-interval to every 5 seconds however based on the observered stream sync behaviour and relay server log messages:
```
[2022-05-15 22:52:39] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 22:54:39] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 22:56:39] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 22:57:02] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 22:59:02] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:00:19] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:00:34] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:00:35] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:00:50] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:01:05] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:01:20] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:01:21] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:01:36] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:01:51] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:02:07] INFO slave/update_from_master Master accepted streamlist request
```
We can see the update is sporadic.
Master server running 2.4.5 relay server on beta.https://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/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/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/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/2435URL Auth does not post good port2022-04-07T17:32:54ZRa LawaURL Auth does not post good portHi,
URL Auth always posts the first listen-socket port configured in icecast.xml. When both http (port 80) and https (port 443) are enabled, url auth always send port=80 in the post request.
I think, it should send port=80 when the cli...Hi,
URL Auth always posts the first listen-socket port configured in icecast.xml. When both http (port 80) and https (port 443) are enabled, url auth always send port=80 in the post request.
I think, it should send port=80 when the client uses an http request and 443 when it uses an https request.
For url redirection, this would help to produce an url which depends on method used by the client. Redirection to an https url when client uses an https url and http otherwise.
Currently I use an other method to know which method is used. I patched url_add_client to send also tlsmode to the post request.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2434Error GPG key sign for repository (update needed on icecast.org)2022-04-12T12:00:45ZNicolas DerambureError GPG key sign for repository (update needed on icecast.org)Hello,
I've installed the icecast2 package from the opensuse repository some weeks ago doing this :
`sh -c "echo deb http://download.opensuse.org/repositories/multimedia:/xiph/Debian_10/ ./ >>/etc/apt/sources.list.d/icecast.list"`
and...Hello,
I've installed the icecast2 package from the opensuse repository some weeks ago doing this :
`sh -c "echo deb http://download.opensuse.org/repositories/multimedia:/xiph/Debian_10/ ./ >>/etc/apt/sources.list.d/icecast.list"`
and :
`wget -qO - http://icecast.org/multimedia-obs.key | sudo apt-key add -`
Then I gave more weight to the package from opensuse repository using APT pinning in order to download from opensuse and not from debian official repositories.
But today, doing apt update, I get this error :
`W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://download.opensuse.org/repositories/multimedia:/xiph/Debian_10 ./ InRelease: The following signatures were invalid: EXPKEYSIG 77EC2301F23C6AA3 multimedia OBS Project <multimedia@build.opensuse.org>
W: Failed to fetch http://download.opensuse.org/repositories/multimedia:/xiph/Debian_10/./InRelease The following signatures were invalid: EXPKEYSIG 77EC2301F23C6AA3 multimedia OBS Project <multimedia@build.opensuse.org>`
It seems the key is not signing correctly the repository now.
I've done again the command :
`wget -qO - http://icecast.org/multimedia-obs.key | sudo apt-key add -`, but the error still persists.
Any change on your side ?
Side question : do you plan to make an icecast package for Debian 11 too ? We need to keep an old server on Debian 10 only for Icecast, and we'll be enchanted to switch it off ;)
Thx !https://gitlab.xiph.org/xiph/icecast-server/-/issues/2433Icecast2.5 beta3 crash with FLAC relay2023-06-07T13:00:21ZSySERRIcecast2.5 beta3 crash with FLAC relayOne of Icecast2 servers is playing a stream in FLAC format in an OGG container. If I configure this as a relay on another Icecast2 2.5 beta3 server, it crashes immediately after Icecast2 2.5 beta3 startup.
The stream with the problem, wh...One of Icecast2 servers is playing a stream in FLAC format in an OGG container. If I configure this as a relay on another Icecast2 2.5 beta3 server, it crashes immediately after Icecast2 2.5 beta3 startup.
The stream with the problem, which plays without any problems.
The configuration for the relay is as follows:
```
<mount>
<mount-name>/oxygenmusic_flac</mount-name>
<relay>
<upstream type="normal">
<uri>http://oxygenmusic.hu:8000/oxygenmusic_flac</uri>
</upstream>
</relay>
</mount>
```
error.log:
```
[2022-03-20 08:46:24] INFO stats/_stats_thread stats thread started
[2022-03-20 08:46:24] INFO fserve/fserve_initialize file serving started
[2022-03-20 08:46:24] INFO main/main Icecast 2.4.99.3 server started
[2022-03-20 08:46:24] INFO main/main Server's PID is 13519
[2022-03-20 08:46:24] INFO main/__log_system_name Running on mscppro-dev; OS: Linux 4.9.0-15-amd64, mscppro-dev, #1 SMP Debian 4.9.258-1 (2021-03-08), x86_64; Address Bits: 64
[2022-03-20 08:46:24] INFO main/__log_system_name From configuration: Our hostname is "dev2.mscp.pro", located "MSCP", with admin contact "mscp@localhost"
[2022-03-20 08:46:24] DBUG yp/yp_recheck_config Updating YP configuration
[2022-03-20 08:46:24] INFO yp/yp_update_thread YP update thread started
[2022-03-20 08:46:24] INFO connection/get_tls_certificate No TLS capability on any configured ports
[2022-03-20 08:46:24] DBUG listensocket/listensocket_accept Client (sock=8, ip="::ffff:127.0.0.1") on socket 0x5556491a7fc0 (-).
[2022-03-20 08:46:24] DBUG client/client_create Client 0x5556491b7bc0 created on connection 0x5556491b7b40 (connection ID: 0, sock=8, socket real: 0x5556491a7fc0 (-), socket effective: 0x5556491a7fc0 (-); global: 1 of 2000)
[2022-03-20 08:46:24] DBUG listensocket/listensocket_accept Client (sock=9, ip="::ffff:127.0.0.1") on socket 0x5556491a7fc0 (-).
[2022-03-20 08:46:24] DBUG client/client_create Client 0x5556491b7ff0 created on connection 0x5556491b7f70 (connection ID: 1, sock=9, socket real: 0x5556491a7fc0 (-), socket effective: 0x5556491a7fc0 (-); global: 2 of 2000)
[2022-03-20 08:46:24] DBUG client/client_destroy Called to destroy client 0x5556491b7bc0 on connection 0x5556491b7b40 (connection ID: 0, sock=8)
[2022-03-20 08:46:24] DBUG connection/connection_close Closing connection 0x5556491b7b40 (connection ID: 0, sock=8)
[2022-03-20 08:46:24] DBUG client/client_destroy Called to destroy client 0x5556491b7ff0 on connection 0x5556491b7f70 (connection ID: 1, sock=9)
[2022-03-20 08:46:24] DBUG connection/connection_close Closing connection 0x5556491b7f70 (connection ID: 1, sock=9)
[2022-03-20 08:46:25] DBUG stats/modify_node_event update global clients (1)
[2022-03-20 08:46:25] DBUG stats/modify_node_event update global connections (1)
[2022-03-20 08:46:25] DBUG stats/modify_node_event update global clients (2)
[2022-03-20 08:46:25] DBUG stats/modify_node_event update global connections (2)
[2022-03-20 08:46:25] DBUG stats/modify_node_event update global clients (1)
[2022-03-20 08:46:25] DBUG stats/modify_node_event update global clients (0)
[2022-03-20 08:46:25] DBUG slave/_slave_thread checking master stream list
[2022-03-20 08:46:25] DBUG slave/check_relay_stream Adding relay source at mountpoint "/oxygenmusic_flac"
[2022-03-20 08:46:25] INFO slave/start_relay_stream Starting relayed source at mountpoint "/oxygenmusic_flac"
[2022-03-20 08:46:25] DBUG slave/start_relay_stream For relay on mount "/oxygenmusic_flac", trying upstream #0
[2022-03-20 08:46:25] INFO slave/open_relay_connection connecting to oxygenmusic.hu:8000
[2022-03-20 08:46:25] DBUG client/client_create Client 0x7fac880015b0 created on connection 0x7fac88001340 (connection ID: 2, sock=8, socket real: (nil) (-), socket effective: (nil) (-); global: 1 of 2000)
[2022-03-20 08:46:25] DBUG client/client_complete Client 0x7fac880015b0 has request_body_length=-1
[2022-03-20 08:46:25] DBUG connection/connection_complete_source sources count is 0
[2022-03-20 08:46:25] DBUG source/source_apply_mount Applying mount information for "/oxygenmusic_flac"
[2022-03-20 08:46:25] DBUG source/source_apply_mount YP changed to 1
[2022-03-20 08:46:25] DBUG source/source_update_settings public set to 1
[2022-03-20 08:46:25] DBUG source/source_update_settings max listeners to -1
[2022-03-20 08:46:25] DBUG source/source_update_settings queue size to 524288
[2022-03-20 08:46:25] DBUG source/source_update_settings burst size to 196608
[2022-03-20 08:46:25] DBUG source/source_update_settings source timeout to 2
[2022-03-20 08:46:25] DBUG source/source_update_settings fallback_when_full to 0
[2022-03-20 08:46:25] DBUG connection/connection_complete_source source is ready to start
[2022-03-20 08:46:25] DBUG source/source_init Source creation complete
[2022-03-20 08:46:25] DBUG format-vorbis/initial_vorbis_page checking for vorbis codec
[2022-03-20 08:46:25] DBUG format-theora/initial_theora_page checking for theora codec
[2022-03-20 08:46:25] DBUG format-midi/initial_midi_page checking for MIDI codec
[2022-03-20 08:46:25] DBUG format-flac/initial_flac_page checking for FLAC codec
[2022-03-20 08:46:25] INFO format-flac/initial_flac_page seen initial FLAC header
[2022-03-20 08:46:25] DBUG format-ogg/format_ogg_attach_header attaching BOS page
[2022-03-20 08:46:25] DBUG format-ogg/format_ogg_attach_header attaching header page
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2431max listeners per one mountpoint2022-11-09T10:39:36ZCYBimax listeners per one mountpointHi, it looks like, there is limit for 20000 concurrent users per one mountpoint. Is that correct?
Thanks
Icecast 2.4.4Hi, it looks like, there is limit for 20000 concurrent users per one mountpoint. Is that correct?
Thanks
Icecast 2.4.4https://gitlab.xiph.org/xiph/icecast-server/-/issues/2430The Playlist does not display the time the song was played.2022-03-15T15:11:37ZPhilipp SchafftThe Playlist does not display the time the song was played.The playlist currently adheres XSPF fully, so there are no timestamps. However it might be useful. It may be added using extentions (likely using a `<meta>` element).
See also parent ticket #2428.The playlist currently adheres XSPF fully, so there are no timestamps. However it might be useful. It may be added using extentions (likely using a `<meta>` element).
See also parent ticket #2428.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2429/admin/version.xsl is not installed2022-03-15T10:23:11ZPhilipp Schafft/admin/version.xsl is not installed`/admin/version.xsl` is not installed. (Missing in `nobase_dist_admin_DATA`.)`/admin/version.xsl` is not installed. (Missing in `nobase_dist_admin_DATA`.)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2428issues Icecast version 2.5 beta32023-01-03T10:13:09ZMichelissues Icecast version 2.5 beta3Test on Debian 9
So far, the following issues / missing things:
- The Playlist does not display the time the song was played.
- Last song number cannot be set.
- It still does not display the song title in Opus and FLAC formats. (Tested...Test on Debian 9
So far, the following issues / missing things:
- The Playlist does not display the time the song was played.
- Last song number cannot be set.
- It still does not display the song title in Opus and FLAC formats. (Tested with MPD and RadioBOSS)
- /admin/version.xsl site: Could not parse XSLT file, Error code: f86b5b28-c1f8-49f6-a4cd-a18e2a6a44fd
- If the number of listeners reaches the number of allowed connections, then the admin page will display an error message, so it cannot be used either.