Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2024-01-06T03:52:01Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2478Request: Make status-json.xslt a real JSON REST API endpoint (Github #65)2024-01-06T03:52:01Z/usr/local/ΕΨΗΕΛΩΝRequest: Make status-json.xslt a real JSON REST API endpoint (Github #65)# TL:DR;
Please make sure that icecast status-json.xslt returns a singleton array of `source` when there is a single source available, to allow consumers using an object-oriented model of icecast output for scraping.
----
As a programm...# TL:DR;
Please make sure that icecast status-json.xslt returns a singleton array of `source` when there is a single source available, to allow consumers using an object-oriented model of icecast output for scraping.
----
As a programmer, I enjoy integrating open systems that speak popular protocols.
I was working on a mobile front end for icecast2 and I found that icecast exposes a JSON API to parse the available streams. I worked with Angular to process it.
I found that the JSON is generated by an XSL transform, which produces an output that in the REST paradigm is not easy to work with.
In XML, especially if you have a schema defined, you can easily tell whether the `<source>` tag appears once or multiple times, and multiple tags appear at the same level. In JSON, the `source` must be either an object or an array for the client to parse it **easily**
The problem is, look at these outputs when you have a single stream running, or multiple:
```json
{
"icestats": {
"admin": "example@localhost",
"host": "localhost",
"location": "somewhere",
"server_id": "Icecast 2.4.4",
"server_start": "Tue, 06 Jun 2023 09:33:57 +0000",
"server_start_iso8601": "2023-06-06T09:33:57+0000",
"source": [
{
...
"listenurl": "http://localhost:8000/silent2.ogg",
"server_description": "Unspecified description",
"server_name": "The Silent Party",
...
},
{
...
"listenurl": "http://localhost:8000/stream",
"server_description": "Unspecified description",
....
}
]
}
}
```
```json
{
"icestats": {
"admin": "example@localhost",
"host": "localhost",
"location": "somewhere",
"server_id": "Icecast 2.4.4",
"server_start": "Tue, 06 Jun 2023 09:33:57 +0000",
"server_start_iso8601": "2023-06-06T09:33:57+0000",
"source": {
"audio_bitrate": 128000,
....
"listenurl": "http://localhost:8000/silent2.ogg",
"server_description": "Unspecified description",
"server_name": "The Silent Party",
....
}
}
}
```
As you can see, if there is a single stream, then the object is a map. Otherwise, it's an array.
Software working on JSON has to suffer additional burden (i.e. more code, more tests, less reliability) to handle the icecast output compared to the straight solution of using an array for the source_s_.
Here is my solution for an Angular app
```typescript
export interface IcecastStatsDto {
admin?: string;
client_connections?: number;
....
stats_connections?: number;
source?: IcecastSourceDto | IcecastSourceDto[];
}
```
And some typescript code to change the `IcecastSourceDto | IcecastSourceDto[]` into a (singleton?) array
```typescript
private getArrayFromSingleValue(x?: IcecastSourceDto | IcecastSourceDto[]): IcecastSourceDto[] {
if (!x) {
return <IcecastSourceDto[]>[];
} else if ('filter' in x) {
return <IcecastSourceDto[]>x;
} else if ('server_url' in x) {
return <IcecastSourceDto[]>[<IcecastSourceDto>x];
} else {
return <IcecastSourceDto[]>[];
}
}
```
This is for a Javascript FE. If I was using a C# or Java application, decoding icecast output into a POCO/POJO woulc be much harder. Defining a singleton array (i.e. an array containing one element) is the preferred solution in OO world,
I hope my feedback will be useful to improve the softwarehttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2476Support for linking well known IDs from metadata2023-06-07T08:36:00ZPhilipp SchafftSupport for linking well known IDs from metadataIt would be nice if Icecast could auto link data when there is a well known ID for it. This is the case with e.g. MusicBrainz.
There should be a boolean setting that can be used to turn this off (e.g. for legal reasons).
This may also ...It would be nice if Icecast could auto link data when there is a well known ID for it. This is the case with e.g. MusicBrainz.
There should be a boolean setting that can be used to turn this off (e.g. for legal reasons).
This may also be implemented on top of #2475 by adding defaults to it.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2475Content resolver support2023-06-07T09:04:02ZPhilipp SchafftContent resolver supportAs there is not yet been a content resolver set up for Icecast and/or the foundation I would like to suggest the following:
Icecast should be extended with a set of settings used to generate URLs for content resolver requests. Initially...As there is not yet been a content resolver set up for Icecast and/or the foundation I would like to suggest the following:
Icecast should be extended with a set of settings used to generate URLs for content resolver requests. Initially there should be support for generating links to documentation. Other types (such as fetches) might later be added.
The I suggest to allow a template style URLs as values with `%`-prefixed parameters to be substituted.
As a reference "`ise-uri-template`" (`82ebe8fa-8b04-415a-ba90-16267465ef71`) defines:
> A URI template for accessing a resolver. This should not be used directly but my using one of the relations derived from it. Such templates are meant to be attached to contexts to allow easy access to resolvers without the need to set direct URIs on every tag.
>
> Templates are used as is with the following variables replaced by correctly URI encoded values. If a given value is not available this template is not available.
>
> * "%I": Any ISE of the tag
> * "%U": The UUID of the tag
> * "%O": The OID of the tag
> * "%R": The URI of the tag
>
> The use of those values is mostly safe as "%" is a special character in URIs that can only be followed by digits, or the letters "a" to "f". However some applications generate invalidly encoded Unicode URIs containing values in the form of "%uNNNN". Those are invalid by themself and therefore not valid in such templates.
I would like to extend that by providing three more substitutions:
* A generic one for the identifier (in any type/encoding)
* The name of the type/encoding used
* The name of the type/encoding used but the value `ise` for any ISE type (UUID, OID, URI).
If such parameters are added a note should be added to the code to make clear that they do not follow the `ise-uri-template` rules. However they may be added or at least reserved for `ise-uri-template` to avoid future syntax collisions.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): #2231https://gitlab.xiph.org/xiph/icecast-server/-/issues/2471listener_remove 2.5 beta not appear if listener creates two connection at the...2023-05-12T10:21:13ZHans-Georg Althofflistener_remove 2.5 beta not appear if listener creates two connection at the same timeI am using kh 2.4.0 kh20 and I am sure that this 64-bit build is based on 2.5 beta.
If a listener creates two connections at the same time, icecast creates two different client ids, which is absolut correct.
If the first of the two conne...I am using kh 2.4.0 kh20 and I am sure that this 64-bit build is based on 2.5 beta.
If a listener creates two connections at the same time, icecast creates two different client ids, which is absolut correct.
If the first of the two connection is closed, icecast is sending a `listener_remove` POST request. That is alright.
But if the second connection is also closed, no additional `listener_remove` POST request is send!
That should no be the case!
My MySQL database for this client id is therefore not closed and appear still at an active connection.
With the ols 2.4.4 32-bit version it works fine.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2470Missing documentation for version 'latest'2023-04-06T12:15:53ZJonas L.Missing documentation for version 'latest'Documentation for some versions is missing on the website https://icecast.org/docs/:
- https://icecast.org/docs/icecast-latest
- https://icecast.org/docs/icecast-2.4.4Documentation for some versions is missing on the website https://icecast.org/docs/:
- https://icecast.org/docs/icecast-latest
- https://icecast.org/docs/icecast-2.4.4Marvin ScholzMarvin Scholzhttps://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/2468lost TCP connections of relays are not handled gracefully2023-04-06T22:19:52ZBjoern Jackelost TCP connections of relays are not handled gracefullyI'm running icecast with a mointpoint that has both a IPv4 and a IPv6 address. IPv4 and IPv6 traffic go over different providers, so this is also being done for redundancy reasons.
I tested how well icecast handles the fallback from the...I'm running icecast with a mointpoint that has both a IPv4 and a IPv6 address. IPv4 and IPv6 traffic go over different providers, so this is also being done for redundancy reasons.
I tested how well icecast handles the fallback from the IPv4 path to the IPv6 path or vice versa by killing the TCP connection or changing the route to "unreachable". It turns out that icecast connects to the other IPv4 or IPv6 path but connected clients will lose their connection immediately, which is bad. Of course we don't want to lose all our users and hope for them to reconnect to our stream in case of such a fallback in our upstream mount.
I tested exactly the same szenario with https://rocketbroadcaster.com/streaming-audio-server - and the Rocket Streaming Audio Server *does* handle this gracefully. The only thing that I was able to notice from the client side here was an ffmped audio decoding error message when the RSAS switched from the one path to the other path. But the switch was almost not noticable by clients.
It would be great if icecast would handle such a case as gracefully as the Rocket Streaming Audio Server.https://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/2465Add support for RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token...2023-03-18T10:25:42ZPhilipp SchafftAdd support for RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token UsageSupport for RFC 6750 should be added. In a first iteration this only needs to be supported by the `url` and the `enforce-auth` backend.
See also: xiph/icecast-libshout#2311Support for RFC 6750 should be added. In a first iteration this only needs to be supported by the `url` and the `enforce-auth` backend.
See also: xiph/icecast-libshout#2311Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2339Remove getters2023-03-09T10:19:51ZPhilipp SchafftRemove gettersCurrently libshout provides a number of getters for several settings. It seems unclear to me what they are useful for. Therefore I suggest to deprecate them and remove them with the next ABI change.
List of relevant getters:
* `shout_ge...Currently libshout provides a number of getters for several settings. It seems unclear to me what they are useful for. Therefore I suggest to deprecate them and remove them with the next ABI change.
List of relevant getters:
* `shout_get_host()`
* `shout_get_port()`
* `shout_get_agent()`
* `shout_get_tls()` There is/was/might be confusion on whether this returns the configuration or the current value.
* `shout_get_ca_directory()`
* `shout_get_ca_file()`
* `shout_get_allowed_ciphers()` The value is not supposed to be set by the API user. Therefore a getter may be still be good (e.g. for status display).
* `shout_get_user()`
* `shout_get_password()` Via #2338
* `shout_get_client_certificate()`
* `shout_get_mount()`
* `shout_get_audio_info()`
* `shout_get_meta()`
* `shout_get_public()`
* `shout_get_content_language()`
* `shout_get_content_format()`
* `shout_get_protocol()` There is/was/might be confusion on whether this returns the configuration or the current value.
* `shout_get_nonblocking()` The returned value is a `SHOUT_BLOCKING_xxx` constant. There had been confusion on this before.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2338Removal of shout_get_password()2023-03-09T10:13:57ZPhilipp SchafftRemoval of shout_get_password()Currently libshout allows the retrieval of the user password via `shout_get_password()`. To me it seems like this is a very strange usecase. Specifically with a security relevant information like the user's password. Therefore I suggest ...Currently libshout allows the retrieval of the user password via `shout_get_password()`. To me it seems like this is a very strange usecase. Specifically with a security relevant information like the user's password. Therefore I suggest to deprecate this function and remove it with the next ABI change.
Notes:
* Removal of the function will clean up the code slightly.
* The information is still within the process' memory. This does not improve security against attacks. The main intention of this ticket is to hint developers into not using bad patterns.Thomas B. RückerThomas B. Rückerhttps://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/2461Converting URL auth to use string renderer.2023-02-27T11:48:36ZPhilipp SchafftConverting URL auth to use string renderer.Currently the URL auth backend builds it's POST data itself. This should be migrated to use string renderer. The code from URL events can be used as a template.Currently the URL auth backend builds it's POST data itself. This should be migrated to use string renderer. The code from URL events can be used as a template.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2337TLS connections not shutting down correctly (blocking mode)2023-02-19T15:44:55ZMoritz GrimmTLS connections not shutting down correctly (blocking mode)shout_tls_close() does not check the return value of SSL_shutdown() to complete a bidirectional shutdown. As a result the TLS connection to Icecast remains open when using libshout in blocking mode. As a result, ezstream users are unable...shout_tls_close() does not check the return value of SSL_shutdown() to complete a bidirectional shutdown. As a result the TLS connection to Icecast remains open when using libshout in blocking mode. As a result, ezstream users are unable to terminate and restart their streams (Icecast prevents multiple source connections to the same mountpoint). See https://gitlab.xiph.org/xiph/ezstream/-/issues/2269 for reference.
A naive patch that solves the issue is attached as [SSL_shutdown.diff](/uploads/0b95fd60e6b3293400fbf3344e7988b8/SSL_shutdown.diff), but that won't work in non-blocking mode ...https://gitlab.xiph.org/xiph/icecast-libigloo/-/issues/7./configure CFLAGS='-flto -O2' triggers lto-type-mismatch warnings between sr...2023-02-06T11:29:48ZPetr Pisar./configure CFLAGS='-flto -O2' triggers lto-type-mismatch warnings between src/igloo.c and src/ro.cWhen building with gcc-13.0.1 and link-time optimization is enabled (-flto), the compiler warns about mismatching function prototypes among compilation units:
~~~~
/bin/sh ./libtool --tag=CC --mode=link gcc -O2 -flto=auto -ffat-lto-...When building with gcc-13.0.1 and link-time optimization is enabled (-flto), the compiler warns about mismatching function prototypes among compilation units:
~~~~
/bin/sh ./libtool --tag=CC --mode=link gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=z13 -mtune=z14 -fasynchronous-unwind-tables -fstack-clash-protection -Wextra -pthread -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -o libigloo.la -rpath /usr/lib64 src/igloo.lo src/error.lo src/rwlock.lo src/time.lo src/feature.lo src/list.lo src/digest.lo src/prng.lo src/cs.lo src/sp.lo src/ro.lo src/tap.lo src/uuid.lo -lm -lrhash -lpthread
libtool: link: gcc -shared -fPIC -DPIC src/.libs/igloo.o src/.libs/error.o src/.libs/rwlock.o src/.libs/time.o src/.libs/feature.o src/.libs/list.o src/.libs/digest.o src/.libs/prng.o src/.libs/cs.o src/.libs/sp.o src/.libs/ro.o src/.libs/tap.o src/.libs/uuid.o -lm -lrhash -lpthread -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -O2 -flto=auto -g -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=z13 -mtune=z14 -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -pthread -Wl,-soname -Wl,libigloo.so.0 -o .libs/libigloo.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libigloo.so.0" && ln -s "libigloo.so.0.0.0" "libigloo.so.0")
libtool: link: (cd ".libs" && rm -f "libigloo.so" && ln -s "libigloo.so.0.0.0" "libigloo.so")
libtool: link: ( cd ".libs" && rm -f "libigloo.la" && ln -s "../libigloo.la" "libigloo.la" )
make[1]: Leaving directory '/builddir/build/BUILD/libigloo-0.9.2'
./include/igloo/ro.h:178:17: warning: type of 'igloo_ro_ref_raw' does not match original declaration [-Wlto-type-mismatch]
178 | igloo_error_t igloo_ro_ref_raw(igloo_ro_t self, igloo_ro_t *out, const igloo_ro_type_t *type);
| ^
src/ro.c:446:17: note: type mismatch in parameter 1
446 | igloo_error_t igloo_ro_ref_raw(igloo_ro_t self, igloo_ro_t *out, const igloo_ro_type_t *type)
| ^
src/ro.c:446:17: note: 'igloo_ro_ref_raw' was previously declared here
src/ro.c:446:17: note: code may be misoptimized unless '-fno-strict-aliasing' is used
./include/igloo/ro.h:183:17: warning: type of 'igloo_ro_weak_ref_replace_raw' does not match original declaration [-Wlto-type-mismatch]
183 | igloo_error_t igloo_ro_weak_ref_replace_raw(igloo_ro_t self, igloo_ro_t *out, const igloo_ro_type_t *type);
| ^
src/ro.c:658:17: note: type mismatch in parameter 1
658 | igloo_error_t igloo_ro_weak_ref_replace_raw(igloo_ro_t self, igloo_ro_t *out, const igloo_ro_type_t *type)
| ^
src/ro.c:658:17: note: 'igloo_ro_weak_ref_replace_raw' was previously declared here
src/ro.c:658:17: note: code may be misoptimized unless '-fno-strict-aliasing' is used
src/private.h:72:12: warning: type of 'igloo_ro_get_instance_unsafe' does not match original declaration [-Wlto-type-mismatch]
72 | igloo_ro_t igloo_ro_get_instance_unsafe(igloo_ro_t self, const igloo_ro_type_t *type);
| ^
src/ro.c:974:12: note: return value type mismatch
974 | igloo_ro_t igloo_ro_get_instance_unsafe(igloo_ro_t self, const igloo_ro_type_t *type)
| ^
src/ro.c:974:12: note: 'igloo_ro_get_instance_unsafe' was previously declared here
src/ro.c:974:12: note: code may be misoptimized unless '-fno-strict-aliasing' is used
./include/igloo/ro.h:189:17: warning: type of 'igloo_ro_stringify_raw' does not match original declaration [-Wlto-type-mismatch]
189 | igloo_error_t igloo_ro_stringify_raw(igloo_ro_t self, char **result, igloo_ro_sy_t flags, const igloo_ro_type_t *type);
| ^
src/ro.c:757:17: note: type mismatch in parameter 1
757 | igloo_error_t igloo_ro_stringify_raw(igloo_ro_t self, char **result, igloo_ro_sy_t flags, const igloo_ro_type_t *type)
| ^
src/ro.c:757:17: note: 'igloo_ro_stringify_raw' was previously declared here
src/ro.c:757:17: note: code may be misoptimized unless '-fno-strict-aliasing' is used
./include/igloo/ro.h:175:12: warning: type of 'igloo_RO_TO_TYPE_raw' does not match original declaration [-Wlto-type-mismatch]
175 | igloo_ro_t igloo_RO_TO_TYPE_raw(igloo_ro_t object, const igloo_ro_type_t *type) igloo_ATTR_F_HOT;
| ^
src/ro.c:250:17: note: return value type mismatch
250 | igloo_ro_t igloo_RO_TO_TYPE_raw(igloo_ro_t object, const igloo_ro_type_t *type)
| ^
src/ro.c:250:17: note: 'igloo_RO_TO_TYPE_raw' was previously declared here
src/ro.c:250:17: note: code may be misoptimized unless '-fno-strict-aliasing' is used
src/private.h:74:21: warning: type of 'igloo_instance_get_prng_state' does not match original declaration [-Wlto-type-mismatch]
74 | igloo_prng_state_t *igloo_instance_get_prng_state(igloo_ro_t self, size_t *instancelen);
| ^
src/igloo.c:314:21: note: type mismatch in parameter 1
314 | igloo_prng_state_t *igloo_instance_get_prng_state(igloo_ro_t self, size_t *instancelen)
| ^
src/igloo.c:314:21: note: 'igloo_instance_get_prng_state' was previously declared here
src/igloo.c:314:21: note: code may be misoptimized unless '-fno-strict-aliasing' is used
src/private.h:73:19: warning: type of 'igloo_instance_get_stringpool_state' does not match original declaration [-Wlto-type-mismatch]
73 | igloo_sp_state_t *igloo_instance_get_stringpool_state(igloo_ro_t self);
| ^
src/igloo.c:304:19: note: type mismatch in parameter 1
304 | igloo_sp_state_t *igloo_instance_get_stringpool_state(igloo_ro_t self)
| ^
src/igloo.c:304:19: note: 'igloo_instance_get_stringpool_state' was previously declared here
src/igloo.c:304:19: note: code may be misoptimized unless '-fno-strict-aliasing' is used
~~~~
While the printed lines are character by character equal, it is probably igloo_ro_t type which differ: include/igloo/types.h defines it as a union of igloo_RO_TYPE()s or as "void *" depending on igloo_ATTR_T_TRANSPARENT_UNION macro. Further, an union member "igloo_RO_TYPE(igloo_ro_stub_t)" expands to "subtype__igloo_ro_stub_t *". Hence different types. src/igloo.c and src/ro.c probably differ in a list of included header files. I agree that the GCC warning is not much helpful. The warning can be triggered with "./configure CFLAGS='-flto -O2'" command.
Problem is that GCC since -O2 optimization level assumes that pointers to different types cannot alias to the same memory and optimizes the code so. This can lead to undefined run-time execution. A brief introduction to strict aliasing can be found at <https://www.geeksforgeeks.org/strict-aliasing-rule-in-c-with-examples/>.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libigloo/-/issues/5Obselete Autoconf macros2023-02-05T13:39:25ZPetr PisarObselete Autoconf macrosWhen regenerating configure script with autoconf-2.71, I can see these warnings:
~~~~
configure.ac:71: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:71: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER...When regenerating configure script with autoconf-2.71, I can see these warnings:
~~~~
configure.ac:71: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:71: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:71: the top level
configure.ac:72: warning: The macro `AC_HEADER_TIME' is obsolete.
configure.ac:72: You should run autoupdate.
./lib/autoconf/headers.m4:743: AC_HEADER_TIME is expanded from...
configure.ac:72: the top level
configure.ac:118: warning: The macro `ACX_PTHREAD' is obsolete.
configure.ac:118: You should run autoupdate.
aclocal.m4:266: ACX_PTHREAD is expanded from...
configure.ac:118: the top level
~~~~~
From Autoconf documentation:
~~~~
-- Macro: AC_HEADER_STDC
This macro is obsolescent. Its sole effect is to make sure that
all the headers that are included by ‘AC_INCLUDES_DEFAULT’ (*note
Default Includes::), but not part of ISO C90, have been checked
for.
All hosted environments that are still of interest for portable
code provide all of the headers specified in ISO C90 (as amended in
1995).
-- Macro: AC_HEADER_TIME
This macro used to check whether it was possible to include
‘time.h’ and ‘sys/time.h’ in the same source file, defining
‘TIME_WITH_SYS_TIME’ if so.
Nowadays, it is equivalent to ‘AC_CHECK_HEADERS([sys/time.h])’,
although it does still define ‘TIME_WITH_SYS_TIME’ for
compatibility’s sake. ‘time.h’ is universally present, and the
systems on which ‘sys/time.h’ conflicted with ‘time.h’ are
obsolete.
~~~~
ACX_PTHREAD was renamed to AX_PTHREAD as can be found in ax_pthread.m4 of autoconf-archive-2022.09.03.Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-libigloo/-/issues/4Outdated FSF address2023-02-01T10:58:38ZPetr PisarOutdated FSF addressCOPYING file quotes a postal address of Free Software Foundation. That address is not valid anymore. Current one can be found at <https://www.gnu.org/licenses/old-licenses/lgpl-2.0.txt>. Please updates the license wording to provide an u...COPYING file quotes a postal address of Free Software Foundation. That address is not valid anymore. Current one can be found at <https://www.gnu.org/licenses/old-licenses/lgpl-2.0.txt>. Please updates the license wording to provide an up-to-date address to your users.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2459Missing documentation for the stats method2023-01-28T20:46:12ZJonas L.Missing documentation for the stats methodHi,
I am unsure if the custom stats method (`curl -X STATS http://icecast:8000`) is deprecated/maintained and if I should use it?
If this can be used in new project, I am looking for some documentation about it. Is there a place where t...Hi,
I am unsure if the custom stats method (`curl -X STATS http://icecast:8000`) is deprecated/maintained and if I should use it?
If this can be used in new project, I am looking for some documentation about it. Is there a place where this already exists?
Thankshttps://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 Scholz