Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2022-05-07T15:37:59Zhttps://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/xiph-qt/-/issues/1026I want to play .ogg audio files in Itunes & xiph programme wont install prope...2007-03-24T00:23:59ZGitlab BotI want to play .ogg audio files in Itunes & xiph programme wont install properly.I have a macintosh g5 with OSX. I downloaded some zipped free .ogg files from the BrianJonestownMassacre (band) website and followed their sketchy and not very in depth instructions. Files now are unzipped and in .ogg format. i want them...I have a macintosh g5 with OSX. I downloaded some zipped free .ogg files from the BrianJonestownMassacre (band) website and followed their sketchy and not very in depth instructions. Files now are unzipped and in .ogg format. i want them to play in Itunes. I downloaded the XiphQT components recommended for modifying the files to play in Quicktime/Itunes. For some reason after following installation procedures the OS claims the Software was succesfully installed but I can't locate it, (though the installer files & other stuff are on the drive.) It does not appear to be properly installed in spite of what the OS tells me. My drive has a partitioned with a drive for software and one for audio. All Itunes files are on the audio drive. What I want to know is how to get these files into Itunes so I can listen to the music. Arek KorbikArek Korbikhttps://gitlab.xiph.org/xiph/xiph-qt/-/issues/941i wonder if i could open a flac file with it installed2006-10-12T22:08:43ZGitlab Boti wonder if i could open a flac file with it installedi have installed some software said that they helps qt to open a flac file,but it can only play it without sound!i installed this,XiphQT,it still doesn't work.i wonder if i really could open a flac file with qt anyway?i have installed some software said that they helps qt to open a flac file,but it can only play it without sound!i installed this,XiphQT,it still doesn't work.i wonder if i really could open a flac file with qt anyway?Arek KorbikArek Korbikhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2488icecast 2.4.4 not supporting ecdsa keys2024-03-03T09:54:02Zbenny1611icecast 2.4.4 not supporting ecdsa keysHello,
I've tried to eneble ssl on my icecast 2.4.4 on my Windows 10 machine. I've requested the certificates using ```certbot```. Then I've created a new listener in my config with the ssl enabled. When I've concatenated the certificate...Hello,
I've tried to eneble ssl on my icecast 2.4.4 on my Windows 10 machine. I've requested the certificates using ```certbot```. Then I've created a new listener in my config with the ssl enabled. When I've concatenated the certificates and the key in my certificate file, I've noticed that the key is considerably smaller than the key I've previously had, but I didn't thnk too much about it, thinking ```icecast``` would just deal with it. When I've tried to connect I've received the following error from FireFox: ```SSL_ERROR_NO_CYPHER_OVERLAP```.
After many hours of research, I've finally came up with a solution: create a RSA key instead of ecdsa (the default for ```certbot```). That worked and I'm up an running on HTTPS. Happy days!
TLDR:
Can you please make ```icecast``` support ```ecdsa``` keys, because that seems to be the default of ```certbot``` now?
Thank you,
Bennyhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2334Icecast 2.5 Beta binaries for Windows (Request)2022-03-21T09:31:42ZRoger HågensenIcecast 2.5 Beta binaries for Windows (Request)The last binary for Windows was beta1 in 2015. Sure I could setup a build environment, but I doubt most Windows users of Icecast build their own Icecast server (myself included).
A windows binary was also desired by Rick Keniuk on the m...The last binary for Windows was beta1 in 2015. Sure I could setup a build environment, but I doubt most Windows users of Icecast build their own Icecast server (myself included).
A windows binary was also desired by Rick Keniuk on the mailing list.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2346Icecast does not support absolute-form, and authority-form requests2018-11-06T08:33:24ZPhilipp SchafftIcecast does not support absolute-form, and authority-form requestsIcecast currently does not support absolute-form, and authority-form requests as per Section 5.3.2/5.3.3 of RFC7230. This is a "MUST" requirement as per RFC.Icecast currently does not support absolute-form, and authority-form requests as per Section 5.3.2/5.3.3 of RFC7230. This is a "MUST" requirement as per RFC.Philipp SchafftPhilipp Schaffthttps://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/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/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/1902Icecast should implement RFC 5334 / 4281 support ("codecs" Media Type parameter)2021-10-30T09:39:38ZThomas B. RückerIcecast should implement RFC 5334 / 4281 support ("codecs" Media Type parameter)Just stumbled into this while working on Opus support in the YP server code.
Proper support for "; codecs=" as specified in RFC 5334 / 4281 in the content-type would be desireable. This could then be used to present proper information i...Just stumbled into this while working on Opus support in the YP server code.
Proper support for "; codecs=" as specified in RFC 5334 / 4281 in the content-type would be desireable. This could then be used to present proper information in the web interface and when submitting to YP. It would also provide hinting for listener clients.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2349Icecast should use libigloo2022-03-16T01:46:29ZPhilipp SchafftIcecast should use libigloocommon/ is currently made into libigloo. Icecast should use libigloo. This ticket is about adding libigloo and using it as replacement to common/common/ is currently made into libigloo. Icecast should use libigloo. This ticket is about adding libigloo and using it as replacement to common/Philipp SchafftPhilipp Schaffthttps://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/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/2467icecast2 crashes frequently2024-01-21T02:16:54ZTom Tomicecast2 crashes frequentlyWe found that icecast2.4.4 often crashes(It has crashed more than a dozen times in the last three days). By checking the system logs, and found that the reasons for the crash are as follows:
```
Apr 4 21:48:56 ubuntu-s-1vcpu-2gb-intel...We found that icecast2.4.4 often crashes(It has crashed more than a dozen times in the last three days). By checking the system logs, and found that the reasons for the crash are as follows:
```
Apr 4 21:48:56 ubuntu-s-1vcpu-2gb-intel-lon1-01 kernel: [46118.223163] icecast2[2005787]: segfault at 4f28 ip 00007f64546dd064 sp 00007fff1d087480 error 4 in libwolfssl.so.24.0.0[7f6454649000+d0000]
Apr 4 21:48:56 ubuntu-s-1vcpu-2gb-intel-lon1-01 kernel: [46118.223177] Code: 84 00 00 00 00 00 f3 0f 1e fa 41 54 55 48 89 fd 48 81 ec a8 00 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 98 00 00 00 31 c0 <0f> b6 87 28 4f 00 00 83 e0 c0 3c 40 74 2e 31 f6 48 89 ef e8 74 75**
Apr 4 21:49:02 ubuntu-s-1vcpu-2gb-intel-lon1-01 systemd[1]: Stopping LSB: Icecast2 streaming media server...
Apr 4 21:49:02 ubuntu-s-1vcpu-2gb-intel-lon1-01 icecast2[2008732]: * Stopping streaming media server icecast2
Apr 4 21:49:02 ubuntu-s-1vcpu-2gb-intel-lon1-01 icecast2[2008732]: ...done.
Apr 4 21:49:02 ubuntu-s-1vcpu-2gb-intel-lon1-01 systemd[1]: icecast2.service: Succeeded.
Apr 4 21:49:02 ubuntu-s-1vcpu-2gb-intel-lon1-01 systemd[1]: Stopped LSB: Icecast2 streaming media server.
```
The operating system we use is: Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-146-generic x86_64)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-ices/-/issues/2327Ices2 glitch between songs2023-11-09T23:51:22ZJhs JdfkIces2 glitch between songsI have a simple playlist of 2 opus small files,
when one ends and second drops I hear a long delay between the two,
and in Potplayer stops playing, as if it detected end of stream.
If I reconnect it plays the next song.
I believe data ...I have a simple playlist of 2 opus small files,
when one ends and second drops I hear a long delay between the two,
and in Potplayer stops playing, as if it detected end of stream.
If I reconnect it plays the next song.
I believe data is not sent back to back, otherwise it would be continuous, and client wouldn't notice anything.
in icecast2 I have tried setting 1MB buffer but still no luck.
Any idea?https://gitlab.xiph.org/xiph/xspf-website/-/issues/16Identifier for "human-readable" elements2021-11-10T03:27:12ZPhilipp SchafftIdentifier for "human-readable" elements# Motivation
Currently content resolvers depend entirely on `<location>`-tag provided URIs and a set of "human-readable" elements. While both do an excellent job in their specific domain there is a gap between. URIs from `<location>` tag...# Motivation
Currently content resolvers depend entirely on `<location>`-tag provided URIs and a set of "human-readable" elements. While both do an excellent job in their specific domain there is a gap between. URIs from `<location>` tags provide a very hard link to data while the "human-readable" elements provide a very soft link. The hard links fail when e.g. the playlist is moved or shared. The soft links fail when data is ambiguous or hard to match (e.g. different languages or spellings are used).
# Suggested change
It is suggested to extend the specification by adding an OPTIONAL attribute "`identifier`" to the "human-readable" elements (see list below). This `identifier`-attribute holds a single URI that works the same way as `<identifier>`. The URI itself is considered a machine readable key, however it is not defined what the result is when actually fetching the given resource.
## Special and non-"human-readable" elements the change shall also apply to
* The `<date>`-tag as defined in 4.1.1.2.8: In case of the `<date>`-tag the `identifier`-attribute refers to a specific and exact event (timestamp). This is useful to denote a "at the same time" relation. While use cases are limited the attribute shall be formally allowed.
* The `<image>`-tag as defined in 4.1.1.2.7 and 4.1.1.2.14.1.1.1.7, the `<license>`-tag as defined in 4.1.1.2.9: In case of the `<image>`- or `<license>`-tag the meaning of the `identifier`-attribute is the same as the meaning of the `<identifier>`-tag would be if the image or license would be given as a `<track>`. This allows resolving of well known images/data e.g. without an internet connection. Well known/common images and licenses may be shipped e.g. by the operating system or a player. A player could provide the user with a gallery of default images and as long as the user uses the same player no network traffic is required for those. While when moved/shared the URI from the tag can be used to resolve the image in a different player. This provides a more efficient way than embedding using data:-URIs.
## Possible updates to elements with an `identifier`-attribute
It should be considered to allow but not recommend tags with an `identifier`-attribute to be empty. Even if this change is not accepted it should be considered to require parsers to allow this while forbid generators to generate such playlists. This may also require an namespace update.
## List of "human-readable" elements
* 4.1.1.2.1 title
* 4.1.1.2.2 creator
* 4.1.1.2.3 annotation
* 4.1.1.2.8 date
* 4.1.1.2.14.1.1.1.3 title
* 4.1.1.2.14.1.1.1.4 creator
* 4.1.1.2.14.1.1.1.5 annotation
* 4.1.1.2.14.1.1.1.8 album
# See also
* If a specific behaviour on fetch/specific result is expected <link> provides a way to link additional metadata from external sources.
# Required version updates
This change will not require namespace update. A version update should be considered.
Allowing previously non-empty tags to be empty requires a namespace update.https://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-ices/-/issues/2323Ignores 'allow-repeats' setting when checking ogg serial2021-12-17T22:18:42ZUnit 193Ignores 'allow-repeats' setting when checking ogg serialOriginally reported in Debian bug [463351](https://bugs.debian.org/463351):
> I currently have a playlist that contains one file, so obviously I need
> to set 'allow-repeats'. However, even with that setting enabled, it
> won't repeat ...Originally reported in Debian bug [463351](https://bugs.debian.org/463351):
> I currently have a playlist that contains one file, so obviously I need
> to set 'allow-repeats'. However, even with that setting enabled, it
> won't repeat the one file because the serial matches (even if I make a
> copy of the file and add the copy to the playlist).
>
> I've changed im_playlist.c so that it checks pl->allow_repeat before
> checking the serial (patch attached).
And as such, it seems we've carried the following patch for the past 10(!) years:
```
Description: allow 'allow-repeats' setting when checking ogg serial
Author: C. Chad Wallace <cwallace@lodgingcompany.com>
Origin: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463351#10
Bug-Debian: http://bugs.debian.org/463351
Forwarded: not-needed
---
src/im_playlist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/src/im_playlist.c 2020-10-07 20:28:50.166655764 -0400
+++ b/src/im_playlist.c 2020-10-07 20:28:50.158655836 -0400
@@ -174,7 +174,7 @@
{
if (ogg_page_bos (&og))
{
- if (ogg_page_serialno (&og) == pl->current_serial)
+ if (!pl->allow_repeat && ogg_page_serialno (&og) == pl->current_serial)
LOG_WARN1 ("detected duplicate serial number reading \"%s\"", pl->filename);
pl->current_serial = ogg_page_serialno (&og);
```https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1782Ignoring metadata comments in ogg1232018-01-22T04:18:37ZnhollandIgnoring metadata comments in ogg123I've made some changes to ogg123 (from vorbis-tools 1.4.0) that allows arbitrary metadata comments to be ignored (=not printed to the screen) when playing files. For example, when a file contains binary album artwork in a comment, this w...I've made some changes to ogg123 (from vorbis-tools 1.4.0) that allows arbitrary metadata comments to be ignored (=not printed to the screen) when playing files. For example, when a file contains binary album artwork in a comment, this would normally result in a lot of garbage to be printed to the screen (in addition to a delay until the playback actually starts). Of course, this can be suppressed with the -q option, but when using that option no comments whatsoever and no playback progress / statistics at all would be printed, which isn't nice either.
As a result, I introduced a new command line switch (-i, --ignore-comments) as well as a new parameter in .ogg123rc (ignore-comments=...) that takes a comma-separated list of comment tags identifying those tags whose comments should not be printed (ignored) upon starting playback. The result is that only the comments specified are ignored, and all other comments as well as any playback statistics are printed as always.
The attached diff contains all the necessary changes to the ogg123 source.Michael SmithMichael Smith