Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2021-10-31T22:11:44Zhttps://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/2423Allow setting the charset globally, not only on per-mount basis2021-11-15T18:41:48ZVadim UshakovAllow setting the charset globally, not only on per-mount basisHi! In my setup, I use a script that manages the sources dynamically, creating, starting and stopping mount points by user request. The icecast config is static, and all the sources share the same login/password. So no need to declare mo...Hi! In my setup, I use a script that manages the sources dynamically, creating, starting and stopping mount points by user request. The icecast config is static, and all the sources share the same login/password. So no need to declare mount points in icecast.xml in that case.
Unfortunately, IceCast uses the charset ISO8859-1 by default, and the only way to override it is declare mount point for each single source and specify `<charset>UTF-8</charset>` for each. This is extremely inconvenient.
I tried the following simple patch and seems to work. It allows to set the charset at the upper level so it takes effect for every mount point that doesn't explicitly override the value. If no charset is set at all, the default ISO8859-1 is used as the last resort.
Could you please merge it?
[global-charset.diff](/uploads/a1b7d890b0ea73d1d12fdf19b7b58209/global-charset.diff)https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2333Support 30X Redirects2021-11-18T14:26:16ZJamie WoodsSupport 30X RedirectsIt would be very useful for libshout to natively handle receiving 301/302 redirects, when connecting as a source.
This would allow various streaming applications to connect to a different Icecast instance dynamically (for example - regi...It would be very useful for libshout to natively handle receiving 301/302 redirects, when connecting as a source.
This would allow various streaming applications to connect to a different Icecast instance dynamically (for example - regional clusters of servers)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2424WARN connection/get_ssl_certificate Invalid cert file /home/icecast/icecast.c...2021-12-03T20:32:49ZAlex SirroshWARN connection/get_ssl_certificate Invalid cert file /home/icecast/icecast.certkeyVersion: icecast-2.4.4-2.1.x86_64 (opensuse)
Cert issuer: LetsEncrypt
File icecast.certkey is world-readable and contains concatenated fullchain.pem and a private key.
P.S.: Found a somewhat related issue on [github](https://github.com...Version: icecast-2.4.4-2.1.x86_64 (opensuse)
Cert issuer: LetsEncrypt
File icecast.certkey is world-readable and contains concatenated fullchain.pem and a private key.
P.S.: Found a somewhat related issue on [github](https://github.com/AzuraCast/AzuraCast/issues/2692)https://gitlab.xiph.org/xiph/ezstream/-/issues/2275FreeBSD compilation2022-08-21T06:45:59ZLászló KárolyiFreeBSD compilationHey,
I tried to contact people on IRC (libera/#xiph) but haven't gotten a timely response so I'm creating an issue here.
I'm trying to compile ezstream for freebsd and after having problems with it, found a way to compile it. I'm not a...Hey,
I tried to contact people on IRC (libera/#xiph) but haven't gotten a timely response so I'm creating an issue here.
I'm trying to compile ezstream for freebsd and after having problems with it, found a way to compile it. I'm not a C coder, nor do I know the toolchain around the code so some advice would be nice here.
The problem was, the code failed to link with iconv because the `-liconv` was missing from `src/Makefile`. I managed to add it to `src/Makefile.am` so it compiled after a `configure` run. Here's a diff for it:
```diff
diff --git a/src/Makefile.am b/src/Makefile.am
index 66f4361..630a944 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -41,7 +41,7 @@ libezstream_la_SOURCES = \
libezstream_la_DEPENDENCIES = \
$(builddir)/libcommon.la \
$(top_builddir)/compat/libcompat.la
-libezstream_la_LIBADD = @EZ_LIBS@ \
+libezstream_la_LIBADD = @EZ_LIBS@ -liconv \
$(libezstream_la_DEPENDENCIES)
bin_SCRIPTS = ezstream-file.sh
@@ -55,7 +55,7 @@ ezstream_cfgmigrate_SOURCES = ezstream-cfgmigrate.c ezconfig0.c
ezstream_cfgmigrate_DEPENDENCIES = \
$(builddir)/libcommon.la \
$(top_builddir)/compat/libcompat.la
-ezstream_cfgmigrate_LDADD = @EZ_LIBS@ \
+ezstream_cfgmigrate_LDADD = @EZ_LIBS@ -liconv \
$(ezstream_cfgmigrate_DEPENDENCIES)
AM_CPPFLAGS = @EZ_CPPFLAGS@ -I$(top_srcdir)/compat
```
I tried to track down the `EZ_LIBS` in configure but got lost and I have no idea as to how to pass it from there so configure would put in src/Makefile, instead of me having to modify `src/Makefile.am`.
Any help is appreciated.László KárolyiLászló Károlyihttps://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/icecast-ices/-/issues/2324Allow building even if libxml2 doesn't ship /usr/bin/xml2-config2022-07-11T00:17:22ZUnit 193Allow building even if libxml2 doesn't ship /usr/bin/xml2-configHowdy,
It seems to be common practice to use pkg-config for these options, but currently if libxml2-dev doesn't contain xml2-config, the package fails to build. The patch below moves to using pkg-config directly.
```
Description: Migr...Howdy,
It seems to be common practice to use pkg-config for these options, but currently if libxml2-dev doesn't contain xml2-config, the package fails to build. The patch below moves to using pkg-config directly.
```
Description: Migrate from using xml2-config to pkg-config
Author: Unit 193 <unit193@debian.org>
---
configure.ac | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/configure.ac 2020-10-07 20:29:12.654454622 -0400
+++ b/configure.ac 2020-10-07 20:29:12.646454694 -0400
@@ -166,9 +166,12 @@
AC_CHECK_FUNCS([gettimeofday ftime])
-XIPH_PATH_XML
-XIPH_VAR_APPEND([XIPH_CFLAGS], [$XML_CFLAGS])
-XIPH_VAR_PREPEND([XIPH_LIBS], [$XML_LIBS])
+PKG_CHECK_MODULES([LIBXML2], [libxml-2.0], [], [
+ AC_MSG_ERROR([${LIBXML2_PKG_ERRORS}. libxml2 is required.])
+])
+
+CFLAGS="${CFLAGS} ${LIBXML2_CFLAGS}"
+LIBS="${LIBS} ${LIBXML2_LIBS}"
XIPH_PATH_SHOUT(, AC_MSG_ERROR([must have libshout installed!]))
if test "$SHOUT_THREADSAFE" != "yes"
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2425Don't hardcode the pkg-config architecture, allowing crossbuilds2021-12-17T23:25:49ZUnit 193Don't hardcode the pkg-config architecture, allowing crossbuildsHowdy,
In Debian, there's a concerted effort to ensure crossbuilding works, the person that puts in the most effort on that submitted this patch:
```
Author: Helmut Grohne <helmutg@debian.org>
Description: FTCBFS: m4/shout.m4 hard code...Howdy,
In Debian, there's a concerted effort to ensure crossbuilding works, the person that puts in the most effort on that submitted this patch:
```
Author: Helmut Grohne <helmutg@debian.org>
Description: FTCBFS: m4/shout.m4 hard codes the build architecture pkg-config
ices2 fails to cross build from source, because it uses the build
architecture pkg-config. The cause is a bad macro in m4/shout.m4. After
fixing it, ices2 cross builds successfully. Please consider applying the
attached patch.
.
Note: I had to remove the setting of PKG_CONFIG_PATH, because Debian's
cross wrapper does not work when PKG_CONFIG_PATH is set. Anyway,
/usr/local/lib/pkgconfig is part of the default search path of
pkg-config, so that should not be a problem.
--- ices2-2.0.2.orig/m4/shout.m4
+++ ices2-2.0.2/m4/shout.m4
@@ -19,22 +19,18 @@
# NB: PKG_CHECK_MODULES exits if pkg-config is unavailable on the target
# system, so we can't use it.
-# seed pkg-config with the default libshout location
-PKG_CONFIG_PATH=${PKG_CONFIG_PATH:-/usr/local/lib/pkgconfig}
-export PKG_CONFIG_PATH
-
# Step 1: Use pkg-config if available
-AC_PATH_PROG([PKGCONFIG], [pkg-config], [no])
-if test "$PKGCONFIG" != "no" && `$PKGCONFIG --exists shout`
+PKG_PROG_PKG_CONFIG
+if test "x$PKG_CONFIG" != x && `$PKG_CONFIG --exists shout`
then
- SHOUT_CFLAGS=`$PKGCONFIG --variable=cflags_only shout`
- SHOUT_CPPFLAGS=`$PKGCONFIG --variable=cppflags shout`
- SHOUT_LIBS=`$PKGCONFIG --libs shout`
+ SHOUT_CFLAGS=`$PKG_CONFIG --variable=cflags_only shout`
+ SHOUT_CPPFLAGS=`$PKG_CONFIG --variable=cppflags shout`
+ SHOUT_LIBS=`$PKG_CONFIG --libs shout`
xt_have_shout="maybe"
else
- if test "$PKGCONFIG" != "no"
+ if test "x$PKG_CONFIG" != x
then
- AC_MSG_NOTICE([$PKGCONFIG couldn't find libshout. Try adjusting PKG_CONFIG_PATH.])
+ AC_MSG_NOTICE([$PKG_CONFIG couldn't find libshout. Try adjusting PKG_CONFIG_PATH.])
fi
# pkg-config unavailable, try shout-config
AC_PATH_PROG([SHOUTCONFIG], [shout-config], [no])
```
This technically applies to the m4 module, which is to have issues filed in icecast-server.
Thanks!Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/ezstream/-/issues/2276Allow reproducible builds, don't hardcode `date` call2022-08-20T23:29:32ZUnit 193Allow reproducible builds, don't hardcode `date` callHowdy,
In order to support reproducible builds, please use `$SOURCE_DATE_EPOCH` if available, falling back to `date` if not. Patch below.
Thanks!
```
Description: Replace hardcoded call to `date` with $SOURCE_DATE_EPOCH
Author: Chris...Howdy,
In order to support reproducible builds, please use `$SOURCE_DATE_EPOCH` if available, falling back to `date` if not. Patch below.
Thanks!
```
Description: Replace hardcoded call to `date` with $SOURCE_DATE_EPOCH
Author: Chris Lamb <lamby@debian.org>
--- a/configure.ac 2016-07-15 10:07:54.491161698 +0200
+++ b/configure.ac 2016-07-15 10:10:13.216666017 +0200
@@ -17,7 +17,7 @@
AC_PROG_FGREP
AC_CANONICAL_HOST
-BUILD_DATE=$(date '+%B %d, %Y')
+BUILD_DATE=$(LC_ALL=C date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}" '+%B %d, %Y')
AC_SUBST([BUILD_DATE])
EXAMPLES_DIR="\$(datadir)/examples/${PACKAGE_TARNAME}"
```Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/flac-website/-/issues/2119Outdated Git URL2021-12-23T15:10:42ZmiaOutdated Git URLThe download page still points to git.xiph.org. Should be updated.The download page still points to git.xiph.org. Should be updated.https://gitlab.xiph.org/xiph/vorbis/-/issues/2344ov_fopen returns undocumented error value2022-01-01T03:49:16ZCarl Banksov_fopen returns undocumented error valueov_fopen is documented as returning one of several error codes, but if the call to fopen fails, it returns -1 (not among the error codes listed).
Recommend to just change documentation to say that a -1 return value means it can't open t...ov_fopen is documented as returning one of several error codes, but if the call to fopen fails, it returns -1 (not among the error codes listed).
Recommend to just change documentation to say that a -1 return value means it can't open the file. I'd guess that a lot of the code out in the field just tests if return value is -1.https://gitlab.xiph.org/xiph/ezstream/-/issues/2277Gapless playback2022-08-20T02:24:32ZY NGapless playbackOn server I use ezstream and icecast.
As client a browser.
If too much silence between tracks client stops playing.
It would be nice to implement gapless playback feature to avoid this.
CheersOn server I use ezstream and icecast.
As client a browser.
If too much silence between tracks client stops playing.
It would be nice to implement gapless playback feature to avoid this.
CheersMoritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/speexdsp/-/issues/4Compiler warnings with comparing singed and unsigned ints2022-01-23T06:22:59ZAnders JenboCompiler warnings with comparing singed and unsigned intsThese are now the only compiler warnings left when building DevilutionX, would be great if we can handle them so we can start checking for compiler warnings in the CI :)
```
In file included from speex_resampler/resample.c:100:
speex_re...These are now the only compiler warnings left when building DevilutionX, would be great if we can handle them so we can start checking for compiler warnings in the CI :)
```
In file included from speex_resampler/resample.c:100:
speex_resampler/resample_sse.h:45:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for (i=0;i<len;i+=8)
~^~~~
speex_resampler/resample_sse.h:62:12: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for(i=0;i<len;i+=2)
~^~~~
speex_resampler/resample_sse.h:84:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for (i=0;i<len;i+=8)
~^~~~
speex_resampler/resample_sse.h:110:12: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for(i=0;i<len;i+=2)
~^~~~
speex_resampler/resample.c:674:20: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for (j=0;j<st->filt_len;j++)
~^~~~~~~~~~~~~
speex_resampler/resample.c:946:21: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for(j=0;j<ichunk;++j)
~^~~~~~~
speex_resampler/resample.c:949:20: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for(j=0;j<ichunk;++j)
~^~~~~~~
speex_resampler/resample.c:1001:19: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for(j=0;j<ichunk;++j)
~^~~~~~~
speex_resampler/resample.c:1008:19: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for(j=0;j<ichunk;++j)
~^~~~~~~
speex_resampler/resample.c:1018:16: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for (j=0;j<ochunk+omagic;++j)
~^~~~~~~~~~~~~~
```https://gitlab.xiph.org/xiph/squishyball/-/issues/1squishyball fails to build against ncurses-6.3: `error: 'TERMINAL' {aka 'stru...2022-01-25T23:08:20ZSergei Trofimovichsquishyball fails to build against ncurses-6.3: `error: 'TERMINAL' {aka 'struct term'} has no member named 'Nttyb'`It's an upstream report of downstream build failure of `squishyball`: https://github.com/NixOS/nixpkgs/pull/146685#issuecomment-1019808697
`ncurses-6.3` removed from public API `Nttyb` and friends in https://github.com/mirror/ncurses/co...It's an upstream report of downstream build failure of `squishyball`: https://github.com/NixOS/nixpkgs/pull/146685#issuecomment-1019808697
`ncurses-6.3` removed from public API `Nttyb` and friends in https://github.com/mirror/ncurses/commit/493e2f7b3fc309879f561a094fdfc15e5304b3d6 effectively breaking the workaround of https://gitlab.xiph.org/xiph/squishyball/-/commit/ce3fabffc3906a23bec09f02db8fdf141f1d4068.
Full build log: https://hydra.nixos.org/log/8myp7pwz36lg93vkzphq2jm0xk4fq4mr-squishyball-19580.drv
Relevant bit:
```
mincurses.c: In function 'setup_term_customize':
mincurses.c:345:20: error: 'TERMINAL' {aka 'struct term'} has no member named 'Nttyb'
345 | term = cur_term->Nttyb;
| ^~
```https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2328MR: fix memleak with -c option2022-01-26T18:11:04Ztaz 007MR: fix memleak with -c optionHello, please merge this patch : https://gitlab.com/taz007/vorbis-tools/-/commit/70604b38f62fcabb37bc1b57dbb9e261c775e067
I can't make a proper MR as I don't have access to fork functionality.Hello, please merge this patch : https://gitlab.com/taz007/vorbis-tools/-/commit/70604b38f62fcabb37bc1b57dbb9e261c775e067
I can't make a proper MR as I don't have access to fork functionality.https://gitlab.xiph.org/xiph/ezstream/-/issues/2278Allow to stream replaygain metadata2022-08-20T02:18:39ZY NAllow to stream replaygain metadataIn order to have equal volume of tracks it would be nice if ezstream could stream replaygain metadata.
replaygain tags are created with
`mp3gain 01-Contaminated.mp3`
the tags are read and applied by
`mpg123 --rva-radio 01-Contaminate...In order to have equal volume of tracks it would be nice if ezstream could stream replaygain metadata.
replaygain tags are created with
`mp3gain 01-Contaminated.mp3`
the tags are read and applied by
`mpg123 --rva-radio 01-Contaminated.mp3`
When however the tracks are streamed via ezstream / icecast the following client setting doesnt correct the volume because the replaygain tags are not streamed
`mpg123 --rva-radio http://icecastserver:8000/mystream`Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/xspf-website/-/issues/24Missing schemas2022-07-08T22:52:53ZAsh ClarkMissing schemasThe links to the XSPF schemas (RelaxNG v1, RNG v0, RNC, XSD) give 404s. I was able to use the online validator but would prefer to have a copy of the RNG for use with the oXygen Editor’s auto-validation feature.The links to the XSPF schemas (RelaxNG v1, RNG v0, RNC, XSD) give 404s. I was able to use the online validator but would prefer to have a copy of the RNG for use with the oXygen Editor’s auto-validation feature.https://gitlab.xiph.org/xiph/vorbis/-/issues/2345Please give a example of how to use RTP vorbis2022-02-18T07:12:32Zyi xinPlease give a example of how to use RTP vorbishttps://gitlab.xiph.org/xiph/speexdsp/-/issues/5Memory leak in JitterBuffer2022-05-09T16:32:40ZRobert AdamMemory leak in JitterBufferI'm referring to the code path at
https://gitlab.xiph.org/xiph/speexdsp/-/blob/master/libspeexdsp/jitter.c#L591-595
which is taken, if the user has registered a custom destroy/free callback (via `JITTER_BUFFER_SET_DESTROY_CALLBACK`). How...I'm referring to the code path at
https://gitlab.xiph.org/xiph/speexdsp/-/blob/master/libspeexdsp/jitter.c#L591-595
which is taken, if the user has registered a custom destroy/free callback (via `JITTER_BUFFER_SET_DESTROY_CALLBACK`). However, contrary to the path that is taken, if no such callback has been registered, the packet's data doesn't seem to get destroyed (by invoking the user-registered callback). At the end of the `else`-block, for this if-statement, `speex_free` is used to that purpose, but as I said: the code path for the custom destroy callback seems to be missing out on this.
If I understand the logic correctly, the packet isn't immediately freed, as in this case, the used data pointer is returned as-is instead of copying the data out of the buffer. Therefore, freeing the data here, would cause the using application to perform a use-after-free when accessing the returned data.
However, the problem seems to be that `jitter->packets[i].data` is set to `NULL`. Therefore, any subsequent logic to check whether a given package has been released already (which appears to be done by checking if `data == NULL`) (e.g. at https://gitlab.xiph.org/xiph/speexdsp/-/blob/master/libspeexdsp/jitter.c#L378), will assume that the data has been freed, where in fact it hasn't (the pointer has only been overwritten with `NULL` without actually freeing the data).https://gitlab.xiph.org/xiph/speexdsp/-/issues/6libspeexdsp.def is missing definitions2022-03-01T12:38:06ZPierre Ferranlibspeexdsp.def is missing definitionslibspeexdsp.def is missing definitions, particularly jitter_buffer_ctl and jitter_buffer_remaining_span, cause the build to not contain all necessary functions on Win32. This issue does not occur on _nix.
See https://github.com/microsof...libspeexdsp.def is missing definitions, particularly jitter_buffer_ctl and jitter_buffer_remaining_span, cause the build to not contain all necessary functions on Win32. This issue does not occur on _nix.
See https://github.com/microsoft/vcpkg/pull/23296