Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-10-12T10:17:30Zhttps://gitlab.xiph.org/xiph/opus/-/issues/2316Assert in celt_decoder when custom modes are disabled2018-10-12T10:17:30ZPhilippe NormandAssert in celt_decoder when custom modes are disabledI can't reproduce this issue outside of WebKit unfortunately. With a libopus built with `--enable-custom-modes=no`, open a youtube video (make sure MediaSource webkit websetting is turned on).
```
Fatal (internal) error in /home/phil/We...I can't reproduce this issue outside of WebKit unfortunately. With a libopus built with `--enable-custom-modes=no`, open a youtube video (make sure MediaSource webkit websetting is turned on).
```
Fatal (internal) error in /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/celt/celt_decoder.c, line 118: assertion failed: st->mode == opus_custom_mode_create(48000, 960, NULL)
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f54bd4e82f1 in __GI_abort () at abort.c:79
#2 0x00007f545143e81f in celt_fatal () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/celt/arch.h:76
#3 0x00007f5451446a65 in validate_celt_decoder () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/celt/celt_decoder.c:118
#4 0x00007f5451446b84 in celt_decode_with_ec () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/celt/celt_decoder.c:867
#5 0x00007f545146d7bf in opus_decode_frame () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/src/opus_decoder.c:518
#6 0x00007f545146eb16 in opus_decode_native () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/src/opus_decoder.c:721
#7 0x00007f545147810a in opus_multistream_decode_native () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/src/opus_multistream_decoder.c:253
#8 0x00007f54514784b9 in opus_multistream_decode () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/src/opus_multistream_decoder.c:398
#9 0x00007f545275c134 in opus_dec_chain_parse_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/ext/opus/gstopusdec.c:630
#10 0x00007f545275d5b3 in gst_opus_dec_handle_frame () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/ext/opus/gstopusdec.c:908
#11 0x00007f54bf915dc9 in gst_audio_decoder_push_buffers () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/gst-libs/gst/audio/gstaudiodecoder.c:1540
#12 0x00007f54bf91615b in gst_audio_decoder_chain_forward () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/gst-libs/gst/audio/gstaudiodecoder.c:1654
#13 0x00007f54bf917377 in gst_audio_decoder_chain () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/gst-libs/gst/audio/gstaudiodecoder.c:1914
#14 0x00007f54bfa0daba in gst_pad_chain_data_unchecked () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4322
#15 gst_pad_push_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4578
#16 0x00007f54bfa15c32 in gst_pad_push () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4697
#17 0x00007f54bfa0daba in gst_pad_chain_data_unchecked () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4322
#18 gst_pad_push_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4578
#19 0x00007f54bfa15c32 in gst_pad_push () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4697
#20 0x00007f54bf9fbcbb in gst_proxy_pad_chain_default () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstghostpad.c:127
#21 0x00007f54bfa0daba in gst_pad_chain_data_unchecked () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4322
#22 gst_pad_push_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4578
#23 0x00007f54bfa15c32 in gst_pad_push () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4697
#24 0x00007f54bf9fbcbb in gst_proxy_pad_chain_default () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstghostpad.c:127
#25 0x00007f54c69d892b in webkitMediaSrcChain(_GstPad*, _GstObject*, _GstBuffer*) () from /home/phil/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37
#26 0x00007f54bfa0daba in gst_pad_chain_data_unchecked () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4322
#27 gst_pad_push_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4578
#28 0x00007f54bfa15c32 in gst_pad_push () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4697
#29 0x00007f54bfb13485 in gst_base_src_loop () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/libs/gst/base/gstbasesrc.c:2957
#30 0x00007f54bfa41cb1 in gst_task_func () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gsttask.c:332
#31 0x00007f54beb78933 in g_thread_pool_thread_proxy () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/glib-2.54.2/glib/gthreadpool.c:307
#32 0x00007f54beb77fd5 in g_thread_proxy () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/glib-2.54.2/glib/gthread.c:784
#33 0x00007f54c06edf2a in start_thread (arg=0x7f54537fe700) at pthread_create.c:463
#34 0x00007f54bd5a8edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
I don't understand this assert, pointer comparison doesn't make much sense to me in this context.https://gitlab.xiph.org/xiph/icecast-common/-/issues/2Namespace assignment2018-10-12T08:50:38ZPhilipp SchafftNamespace assignmentThis subproject should be assigned a namespace for exported symbols and constants. This is closely related to #1.This subproject should be assigned a namespace for exported symbols and constants. This is closely related to #1.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2340authentication subsystem should allow the user to send a custom error2018-10-16T06:39:31ZPhilipp Schafftauthentication subsystem should allow the user to send a custom errorThe authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="a...The authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="anonymous" deny-all="*" reject-with="f955b6c6-aaca-4734-aacc-67d86bf83c3b" />
</authentication>
```
This would also be in-line with `AUTH_ALTER_SEND_ERROR`.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/opusfile/-/issues/2327Build fails with LibreSSL: ./.libs/libopusurl.so: undefined reference to `BIO...2020-06-24T22:38:20ZStefan StroginBuild fails with LibreSSL: ./.libs/libopusurl.so: undefined reference to `BIO_meth_set_puts'LibreSSL 2.6.5, Gentoo Linux.
```
src/http.c: In function ‘op_bio_retry_new’:
src/http.c:1540:3: warning: implicit declaration of function ‘BIO_set_init’; did you mean ‘BIO_sock_init’? [-Wimplicit-function-declaration]
BIO_set_init(_...LibreSSL 2.6.5, Gentoo Linux.
```
src/http.c: In function ‘op_bio_retry_new’:
src/http.c:1540:3: warning: implicit declaration of function ‘BIO_set_init’; did you mean ‘BIO_sock_init’? [-Wimplicit-function-declaration]
BIO_set_init(_b,1);
^~~~~~~~~~~~
BIO_sock_init
src/http.c:1544:3: warning: implicit declaration of function ‘BIO_set_data’; did you mean ‘BIO_set_ex_data’? [-Wimplicit-function-declaration]
BIO_set_data(_b,NULL);
^~~~~~~~~~~~
BIO_set_ex_data
```
and so on.
Full [build.log](/uploads/e3c105fc852d754257bce86f654210a4/build.log)
See also: https://bugs.gentoo.org/588768https://gitlab.xiph.org/xiph/opus/-/issues/2315Minor Issue on libopus 1.3-rc default framesize adjustment2020-04-22T04:19:26ZHeman BusschotsMinor Issue on libopus 1.3-rc default framesize adjustmentHi,
I couldn't post on the IRC for some reason, that's why I want to post it here.
On the libopus 1.3-rc (release candidate), I found it best to change the Framesize setting to 40.
In my case I could increase bitrate from 48kbps to 51kbp...Hi,
I couldn't post on the IRC for some reason, that's why I want to post it here.
On the libopus 1.3-rc (release candidate), I found it best to change the Framesize setting to 40.
In my case I could increase bitrate from 48kbps to 51kbps, where artifacts are hardly heard, while keeping the same file size.
These 3 extra bits, may seem little, but they're the difference between noticeable artifacts at 48kbps (in the stereo spectrum) to nearly fully transparent at 51kbps; all the while keeping the same file size.
Audio quality overall improved slightly thanks to this setting.
Setting it larger or smaller, did not increase quality or decrease filesize.
With that I just want to say that in my opinion, the newer release candidate, runs better with Framesize 40.
It would be nice to further be able to finetune this (between the ranges of 20-60) to see where the exact best setting is located.
The best framesize setting, could be 30, or it could be 45, without the ability to tune it any other than 20, 40, or 60, I wouldn't know...
Not sure if Opus can support such a feature?
Just like CPU complexity is by default set to 10, I think framesize should be set to 40 by default, on the RC candidate (1.3).
Aside from allowing a 6% higher bitrate, while keeping the same file size, it also allows for going much lower in bitrate before capping off the high frequencies.
For instance, For stereo music, I can go as low as 24kbps at almost 48kHz (I think it's capped to 32, but it's mostly inaudible); and for mono I can go as low as 12kbps, before the high frequencies are cut.
Using Framebuffer 20 or 60, has higher tresholds.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2339After logrotate Icecast not using new access.log and error.log files2018-09-28T13:24:06ZDoug TinklenbergAfter logrotate Icecast not using new access.log and error.log filesThe logrotate postrotate command is this for Icecast: */bin/kill -HUP `cat /var/run/icecast/icecast.pid 2>/dev/null` 2> /dev/null || true*
The Icecast installation doesn't create the icecast folder in /var/run so there is no icecast.p...The logrotate postrotate command is this for Icecast: */bin/kill -HUP `cat /var/run/icecast/icecast.pid 2>/dev/null` 2> /dev/null || true*
The Icecast installation doesn't create the icecast folder in /var/run so there is no icecast.pid file.
So what's happening is that after a logrotate the Icecast service continues to use the access.log-date file rather then the new access.log file that is created during the logrotate. The only way to get it to use the new log files is to restart the icecast service.
Why is the logrotate command trying to kill a pid file that doesn't exist and is there another postrotate command that should be used instead.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2338SSL support on Ubuntu 18.042019-01-26T10:42:02ZSimon CechacekSSL support on Ubuntu 18.04Hello,
I am trying to run Icecast on my Ubuntu 18.04 with SSL enabled. When I add the official repository to the system and then use `apt-get install icecast2`, everything will work except that when I will turn the SSL on, I will `get I...Hello,
I am trying to run Icecast on my Ubuntu 18.04 with SSL enabled. When I add the official repository to the system and then use `apt-get install icecast2`, everything will work except that when I will turn the SSL on, I will `get INFO connection/get_ssl_certificate No SSL capability` message, I pre-installed OpenSSL befory icecast installation."
any Idea how to fix this?
I also tried to build by Icecast from the source with the custom path ovf openssl pramater enabled (just put there the default openssl path) and it worked, but this icecast is installed as an app and not as a service, so don't how to reload config without dropping listeners (i need to add relays withour restarting the server as it will server as a proxy).
Thanks for all your time!https://gitlab.xiph.org/xiph/liboggz/-/issues/6assertion failure in oggz_close at oggz.c:218 when scanning corrupted file2018-08-08T17:46:51Zkeelerdaassertion failure in oggz_close at oggz.c:218 when scanning corrupted fileoggz-scan exits with "Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed." when scanning a corrupted file.oggz-scan exits with "Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed." when scanning a corrupted file.conradconradhttps://gitlab.xiph.org/xiph/liboggz/-/issues/5[liboggz] oggz-info reports incorrect duration for chained files2018-08-08T17:46:39ZGArik[liboggz] oggz-info reports incorrect duration for chained filesHi, all
I have:
libvorbis-1.2.3
vorbis-tools-1.2.0
libogg-1.1.4
liboggz-0.9.9 installed on my system.
The problem is that oggz-info unable to detect "Content-Duration" correctly. As the result "Content-Bitrate-Average" is also incorrec...Hi, all
I have:
libvorbis-1.2.3
vorbis-tools-1.2.0
libogg-1.1.4
liboggz-0.9.9 installed on my system.
The problem is that oggz-info unable to detect "Content-Duration" correctly. As the result "Content-Bitrate-Average" is also incorrect. Also slightly different bitrate detection by ogginfo and oggz-info seems strange to me.
Here is an example:
```
lxuser@garik:~/oggz-bug$ ls
test0.ogg test1.ogg
lxuser@garik:~/oggz-bug$ LANG=C ogginfo *.ogg
Processing file "test0.ogg"...
New logical stream (#1, serial: 7f1f032f): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 1984900 bytes
Playback length: 0m:55.546s
Average bitrate: 285.871339 kb/s
Logical stream 1 ended
Processing file "test1.ogg"...
New logical stream (#1, serial: 7f1f0330): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 10962852 bytes
Playback length: 4m:07.520s
Average bitrate: 354.326180 kb/s
Logical stream 1 ended
lxuser@garik:~/oggz-bug$ oggz-info -a *.ogg
Filename: test0.ogg
Content-Duration: 00:00:55.546
Content-Length: 1.897 MB
Content-Bitrate-Average: 286.452 kbps
Vorbis: serialno 2132738863
4617 packets in 467 pages, 9.9 packets/page, 1.098% Ogg overhead
Content-Length: 1.897 MB
Content-Bitrate-Average: 286.452 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.302 kB
Page-Length-StdDev: 230 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 304 bytes
------------------------------------------------------------
Filename: test1.ogg
Content-Duration: 00:04:07.520
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Vorbis: serialno 2132738864
30765 packets in 2577 pages, 11.9 packets/page, 1.116% Ogg overhead
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.297 kB
Page-Length-StdDev: 111 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 298 bytes
lxuser@garik:~/oggz-bug$ cat test0.ogg test1.ogg > test.ogg
lxuser@garik:~/oggz-bug$ LANG=C ogginfo test.ogg
Processing file "test.ogg"...
New logical stream (#1, serial: 7f1f032f): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 1984900 bytes
Playback length: 0m:55.546s
Average bitrate: 285.871339 kb/s
Logical stream 1 ended
New logical stream (#2, serial: 7f1f0330): type vorbis
Vorbis headers parsed for stream 2, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 2:
Total data length: 10962852 bytes
Playback length: 4m:07.520s
Average bitrate: 354.326180 kb/s
Logical stream 2 ended
lxuser@garik:~/oggz-bug$ oggz-info -a test.ogg
Content-Duration: 00:04:07.520
Content-Length: 12.356 MB
Content-Bitrate-Average: 418.738 kbps
Vorbis: serialno 2132738863
4617 packets in 467 pages, 9.9 packets/page, 1.098% Ogg overhead
Content-Length: 1.897 MB
Content-Bitrate-Average: 64.282 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.302 kB
Page-Length-StdDev: 230 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 304 bytes
Vorbis: serialno 2132738864
30765 packets in 2577 pages, 11.9 packets/page, 1.116% Ogg overhead
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.297 kB
Page-Length-StdDev: 111 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 298 bytes
```conradconradhttps://gitlab.xiph.org/xiph/liboggz/-/issues/4[liboggz] oggz-diff unable to process files with whitespace in filename2018-08-08T17:45:36ZGArik[liboggz] oggz-diff unable to process files with whitespace in filenameoggz-diff unable to process files with whitespace in filename.
liboggz compiled from trunk on 21.08.2009 (yesterday)oggz-diff unable to process files with whitespace in filename.
liboggz compiled from trunk on 21.08.2009 (yesterday)Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/liboggz/-/issues/3Buffer overflow in liboggz, httpdate.c, function httpdate_parse2018-08-08T17:44:41ZhannoBuffer overflow in liboggz, httpdate.c, function httpdate_parseThe function httpdate_parse writes 4 bytes to the three byte variables wday and month. These are supposed to store a 3 byte string, however that misses that the string needs a null terminating byte. Making the variables 4 bytes fixes thi...The function httpdate_parse writes 4 bytes to the three byte variables wday and month. These are supposed to store a 3 byte string, however that misses that the string needs a null terminating byte. Making the variables 4 bytes fixes this.
Also the parser string should limit the size of the month string. See attached patch.
This bug was found with the help of address sanitizer. Can be reproduced by compiling liboggz with -fsanitize=address in CFLAGS+LDFLAGS and running make check.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/liboggz/-/issues/1Granulepos corruption with large/numerous packets (with test case)2018-08-08T17:39:26ZstenyakGranulepos corruption with large/numerous packets (with test case)I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both libog...I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both liboggz v1.1.1 (git `70b58a45`, from 2010-04-29) and the head of master (git `f49574ed` from 2014-04-24). Repo URL: https://git.xiph.org/liboggz.git
In the attached test case, the file writing phase seems to go OK, at least no errors are returned anywhere.
[main.cpp](/uploads/f6ad965f431dd89127c12fadeddfa357/main.cpp)
The writer code is based on the example found here: https://xiph.org/oggz/doc/group__force__feed.html#details
The reading phase is more problematic:
- Passing the file through oggz-validate.exe (as downloaded from https://xiph.org/oggz ) crashes with an Out of Memory error
- Using oggz-dump.exe instead, it seems to read all packets correctly, and output the expected granule positions
- The attached source code is unable to finish without errors though.
To verify the problem, follow these steps:
1. Compile the code as-is, in debug mode (to run all asserts). Everything should go ok. The resulting file `foo.oggz` will be around 160 megs.
2. Set `FAIL = true`, compile and run. An assert will fail, around packet #491. The granule position is corrupted now.
3. Decrease packetSize 1 byte (setting it to `packetSize = 163388`), compile and run. Granule position will be okay again, all asserts will pass.
So it seems that both amount of packets and size of packets can contribute to the corrupted granulepos.
If you need any help reproducing the issue, please let me know.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2337RFE: Please add a possibility for a relay to transcode the stream2020-11-09T19:35:07Zpetr tomasekRFE: Please add a possibility for a relay to transcode the streamWith Icecast I'm missing the possibility to create transcoding relays in a simple manner. I'd suggest there could be a new configuration option which would specify a binary/script which the stream would go through.
Something like this:
...With Icecast I'm missing the possibility to create transcoding relays in a simple manner. I'd suggest there could be a new configuration option which would specify a binary/script which the stream would go through.
Something like this:
```xml
<relay>
<server>127.0.0.1</server>
<port>8001</port>
<mount>/example.ogg</mount>
<local-mount>/different.ogg</local-mount>
<on-demand>1</on-demand>
<retry-delay>30</retry-delay>
<relay-shoutcast-metadata>0</relay-shoutcast-metadata>
<transcode-bin>/usr/local/bin/transcodestreamXYZ</transcode-bin>
</relay>
```
Thanks!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2336Icecast 2.5.x relays not working2018-07-26T10:19:39ZPhilipp SchafftIcecast 2.5.x relays not workingRelays do not work.
In master since 4a10d7e74422b7c3a31d4677e12f5aa3ce52474f.
client->request_body_length is not correctly set up leading to body read limit (client->request_body_length=0). client generally may not be in correct state.Relays do not work.
In master since 4a10d7e74422b7c3a31d4677e12f5aa3ce52474f.
client->request_body_length is not correctly set up leading to body read limit (client->request_body_length=0). client generally may not be in correct state.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2301libshout does hang in shout_open().2019-05-14T16:44:28ZPhilipp Schafftlibshout does hang in shout_open().libshout in 062373684bdeedf72d5432b0d247f459cb7fc285 hangs in calls to shout_open() in somecases.
In state SHOUT_STATE_RESP_PENDING it passes retry via (rc == SHOUTERR_SOCKET && self->retry). self->retry does not reach 0.
libshout is in...libshout in 062373684bdeedf72d5432b0d247f459cb7fc285 hangs in calls to shout_open() in somecases.
In state SHOUT_STATE_RESP_PENDING it passes retry via (rc == SHOUTERR_SOCKET && self->retry). self->retry does not reach 0.
libshout is in blocking mode with TLS in RFC2818 mode. Server is Icecast 2.4.1. The reply in question is 401 to a probe request. The non-probe request is sent but the socket is closed by the server.
Maybe related to HTTP keep-alive.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2335`<no-mount>` (`<mount>`'s child) is noop in 2.5.x2021-04-14T10:51:43ZPhilipp Schafft`<no-mount>` (`<mount>`'s child) is noop in 2.5.xThe tag `<no-mount>` (which is a child element of `<mount>`) doesn't seem to do anything in 2.5.x. However according to source code comment it should disallow direct access to the mount.
This may interact with the ACL system.The tag `<no-mount>` (which is a child element of `<mount>`) doesn't seem to do anything in 2.5.x. However according to source code comment it should disallow direct access to the mount.
This may interact with the ACL system.Philipp SchafftPhilipp Schaffthttps://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/2333Make playlist generation consistent2020-10-11T16:28:01ZMarvin ScholzMake playlist generation consistentCurrently all playlist formats are generated using XSLT, but m3u is generated in C code. This should be done consistent, either all as XSLT or all in C code.
Opinions which way will be better welcome!Currently all playlist formats are generated using XSLT, but m3u is generated in C code. This should be done consistent, either all as XSLT or all in C code.
Opinions which way will be better welcome!https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2300SIGPIPE from libshout shout_send when Icecast is stopped2019-06-30T09:54:34ZJustin SouterSIGPIPE from libshout shout_send when Icecast is stoppedI'm getting a SIGPIPE signal from libshout shout_send function when Icecast is stopped. I've tried signal(SIGPIPE, SIG_IGN) and no difference. Trying to implement source client auto re-connect. Building in XCode on macOS High Sierra.I'm getting a SIGPIPE signal from libshout shout_send function when Icecast is stopped. I've tried signal(SIGPIPE, SIG_IGN) and no difference. Trying to implement source client auto re-connect. Building in XCode on macOS High Sierra.https://gitlab.xiph.org/xiph/theora/-/issues/2310Gentoo QA issue with decode.c2018-06-22T17:45:59ZGhost UserGentoo QA issue with decode.cMy GNU/Linux distribution is Gentoo Linux. When installing `media-libs/libtheora-1.1.1-r1` with the Portage package manager I get the following warning message:
```
* QA Notice: Package triggers severe warnings which indicate that it
...My GNU/Linux distribution is Gentoo Linux. When installing `media-libs/libtheora-1.1.1-r1` with the Portage package manager I get the following warning message:
```
* QA Notice: Package triggers severe warnings which indicate that it
* may exhibit random runtime failures.
* /var/tmp/portage/media-libs/libtheora-1.1.1-r1/work/libtheora-1.1.1/lib/decode.c:400:49: warning: iteration 2 invokes undefined behavior [-Waggressive-loop-optimizations]
* Please do not file a Gentoo bug and instead report the above QA
* issues directly to the upstream developers of this software.
* Homepage: https://www.theora.org
```
[build.log.xz](/uploads/fee915344d8156b954b6310b01b7e0e1/build.log.xz)