Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2023-01-03T10:26:01Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2070openSSL configuration overhaul in Icecast2023-01-03T10:26:01ZThomas B. RückeropenSSL configuration overhaul in IcecastI'd like to propose we update Icecast's openSSL configuration to have safer defaults and disable broken protocols and features completely.
Most recent vulnerabilities have been addressed by openSSL and should be up to date on people's sy...I'd like to propose we update Icecast's openSSL configuration to have safer defaults and disable broken protocols and features completely.
Most recent vulnerabilities have been addressed by openSSL and should be up to date on people's systems, but still we should do our part to prevent bad things from happening.
There will be dependent tickets filed for certain aspects.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2063Go through compiler warnings and such2018-03-06T12:49:47ZThomas B. RückerGo through compiler warnings and suchThere are a couple build time warnings from e.g. gcc that might need to be addressed.
This is the top level ticket for such issues. If you create tickets about build time warnings, please put the ID of this ticket: #2063 into the "Paren...There are a couple build time warnings from e.g. gcc that might need to be addressed.
This is the top level ticket for such issues. If you create tickets about build time warnings, please put the ID of this ticket: #2063 into the "Parent Tickets" field of your ticket.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2061Investigate: Relay not recovering2021-10-30T09:42:21ZMarvin ScholzInvestigate: Relay not recoveringAs reported in IRC by AAA_awright, a relay doesn't seem to reconnect if the source mount times out, see attached log. This happened with Icecast 2.3.3, we should check that this does not happen with 2.4.0, it should recover if the source...As reported in IRC by AAA_awright, a relay doesn't seem to reconnect if the source mount times out, see attached log. This happened with Icecast 2.3.3, we should check that this does not happen with 2.4.0, it should recover if the source mountpoint is back.
> I had a problem where one of my relays has stopped relaying, and I couldn't bring it back up without a restart. It's only playing the fallback. It reloads the relay data from the master server, but ignores it somehow. It honors me changing the refresh interval in the config file and everything.
> The event seems to happen at 2014-10-12 05:41:13, and it never recovers or mentions the stream again
> If it helps, I don't see another "checking master stream list" for another 15 minutes: [2014-10-12 06:09:20] DBUG slave/_slave_thread checking master stream list
> Before 05:41, it occurs reliably every 120 secondsThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2060Typos in Vorbis I specification2017-11-01T04:49:44ZstefanTypos in Vorbis I specificationWhile reading through the [Vorbis I specification](https://xiph.org/vorbis/doc/Vorbis_I_spec.pdf), I discovered two minor typos:
*Section 4.3.8*
_"window\_blocksize(previous\_window)/4+window\_blocksize(current\_window)/4"_
should read
...While reading through the [Vorbis I specification](https://xiph.org/vorbis/doc/Vorbis_I_spec.pdf), I discovered two minor typos:
*Section 4.3.8*
_"window\_blocksize(previous\_window)/4+window\_blocksize(current\_window)/4"_
should read
_"window_blocksize(previous_window)/4+window_blocksize(current_window)/4"_
(remove the backslashes)
*Section 10.1*
_"The vector [floor1_inverse_dB_table] is a 256 element static lookup table consiting of the following values (read left to right then top to bottom):"_
_"consiting"_ should read _"consisting"_
It would mean a lot to me if you have time to fix them.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2059[PATCH] Better code style consistency2018-03-06T12:49:47ZMarvin Scholz[PATCH] Better code style consistencyThis patch makes the overall code style more consistent.This patch makes the overall code style more consistent.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2058[PATCH] Replace logging macros2018-03-06T12:49:47ZMarvin Scholz[PATCH] Replace logging macrosReplace the old logging macros with variadic argument macros.
`ERROR0`, `ERROR1`, `ERROR2`, `ERROR3`, `ERROR4` are replaced with `LOG_ERROR`
`WARN0`, `WARN1`, `WARN2`, `WARN3` are replaced with `LOG_WARN`
`INFO0`, `INFO1`, `INFO2`, `INF...Replace the old logging macros with variadic argument macros.
`ERROR0`, `ERROR1`, `ERROR2`, `ERROR3`, `ERROR4` are replaced with `LOG_ERROR`
`WARN0`, `WARN1`, `WARN2`, `WARN3` are replaced with `LOG_WARN`
`INFO0`, `INFO1`, `INFO2`, `INFO3` are replaced with `LOG_INFO`
`DEBUG0`, `DEBUG1`, `DEBUG2`, `DEBUG3`, `DEBUG4` are replaced with `LOG_DEBUG`
Additionally a bit formatting was done, to match common c code style (only where it really shouted for attention, while looking through the files)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2057Rewrite HTTP handling to correctly implement HTTP/1.12018-11-09T14:06:15ZMarvin ScholzRewrite HTTP handling to correctly implement HTTP/1.1Icecast should support HTTP/1.1 especially since we already do this partially for PUT support.
HEAD should probably be added too, since it might be useful and some players maybe do it to check content-type, length…
Additionally to compl...Icecast should support HTTP/1.1 especially since we already do this partially for PUT support.
HEAD should probably be added too, since it might be useful and some players maybe do it to check content-type, length…
Additionally to completely support PUT and stay in spec we need to support chunked encoding.Icecast 2.6Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2054[PATCH] On-Demand relay mount doesn't has on_demand set on startup2018-03-06T12:49:47ZMarvin Scholz[PATCH] On-Demand relay mount doesn't has on_demand set on startupA `<relay>` that has the `on-demand` option set is missing this information on icecast's first startup, when looking at the stats xml
```
<source mount="/diff.mp3">
<listener_peak>0</listener_peak>
<listeners>0</listeners>
...A `<relay>` that has the `on-demand` option set is missing this information on icecast's first startup, when looking at the stats xml
```
<source mount="/diff.mp3">
<listener_peak>0</listener_peak>
<listeners>0</listeners>
<listenurl>http://localhost:8000/diff.mp3</listenurl>
<max_listeners>unlimited</max_listeners>
<public>0</public>
</source>
```
missing the `<on_demand>1</on_demand>` on first startup. When a listener connects and it therefore connects to the relayed stream, it will have this set. The patch makes sure that this is set initially too.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-website/-/issues/2050document the default mount point2017-08-26T22:33:51ZSven Herzbergdocument the default mount pointI researched information about the default mount points (mostly by looking at the code and into #1914).
Here is a trivial patch to add documentation about it (so it can appear in the icecast-trunk documentation folder of the web site).I researched information about the default mount points (mostly by looking at the code and into #1914).
Here is a trivial patch to add documentation about it (so it can appear in the icecast-trunk documentation folder of the web site).Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/opus/-/issues/2048Compiling without optimization produces a warning2017-10-21T19:37:05ZDave MichaelCompiling without optimization produces a warningI work on Chromium, and in my debug build, I always get this warning:
src/src/opus_decoder.c:37:10: warning: You appear to be compiling without optimization, if so opus will be very slow. [-W#pragma-messages]
# pragma message "You appear...I work on Chromium, and in my debug build, I always get this warning:
src/src/opus_decoder.c:37:10: warning: You appear to be compiling without optimization, if so opus will be very slow. [-W#pragma-messages]
# pragma message "You appear to be compiling without optimization, if so opus will be very slow."
^
I personally want my build output to be clean, and I'm perfectly aware when doing a debug build that it's debug and might be slow. So I would prefer if this warning was not there.
If it's not acceptable to simply remove this warning, it seems like it ought to be possible to turn this off with a precompile define so that embedders like Chromium can turn it off. We have a large code base and noise in our build output can be very annoying.
I'm willing to do the patch if there's an acceptable solution to this.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2047Icecast 2.4.0 - status-json.xsl - parse error2018-03-06T12:49:47ZGhost UserIcecast 2.4.0 - status-json.xsl - parse errorHello,
The attached status json file does not parse.
The file is here:
http://www.noizeukradio.com:8000/status-json.xsl
This topic looks similar:
http://icecast.imux.net/viewtopic.php?t=8240
Thanks,
DavidHello,
The attached status json file does not parse.
The file is here:
http://www.noizeukradio.com:8000/status-json.xsl
This topic looks similar:
http://icecast.imux.net/viewtopic.php?t=8240
Thanks,
DavidIcecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/ezstream/-/issues/2045Not sending data to stdin can throw ezstream into an infinite loop2017-08-03T06:12:50ZGuillaume QuintardNot sending data to stdin can throw ezstream into an infinite loopHere's the setup:
first term
avconv -re -i file.mp3 -c:a mp3 -f mpegts udp://127.0.0.1:1234
second term
avconv -i udp://@127.0.0.1:1234 -f mp3 - | ezstream -c conf.xml
Everything works as expected, unless you kill the first comm...Here's the setup:
first term
avconv -re -i file.mp3 -c:a mp3 -f mpegts udp://127.0.0.1:1234
second term
avconv -i udp://@127.0.0.1:1234 -f mp3 - | ezstream -c conf.xml
Everything works as expected, unless you kill the first command, wait for 10-15 seconds then restart it. At this point, ezstream won't resume streaming and will throw thousand of
ezstream: Streaming from standard input
ezstream: No (more) data available on standard input
at you.
It seems the problem comes from streamFile in src/ezstream.c where the file is closed, even if stdin is in use.
Attempted patch is attached for review.
Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/opus-tools/-/issues/2044opus-tools-0.1.9 can not encode samples with !48000 sample rate.2018-05-13T08:51:37Zsnaixopus-tools-0.1.9 can not encode samples with !48000 sample rate.I have test the opus-tools 1.1 to encode wav to opus(ogg container).
But I found that opus-tools output opus just with 48000 sample rate.
for example: I give a wav which is 20500 sample rate; in code, I think opus tools will resample it ...I have test the opus-tools 1.1 to encode wav to opus(ogg container).
But I found that opus-tools output opus just with 48000 sample rate.
for example: I give a wav which is 20500 sample rate; in code, I think opus tools will resample it with speex resampler in 24000 sample rate. but the output opus file always is 48000.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/ogg/-/issues/2043ogg-index produces multiple fisbones with the same name and role, where the i...2020-11-06T04:02:56ZNick Burchogg-index produces multiple fisbones with the same name and role, where the input has several video or audio streamsIf you use OggIndex on a file without a Skeleton stream, which has one Vorbis and one Theora stream in it, the resultant Skeleton fisbones will be correct. However, if you use it on a file with multiple Theora or Vorbis streams, it will ...If you use OggIndex on a file without a Skeleton stream, which has one Vorbis and one Theora stream in it, the resultant Skeleton fisbones will be correct. However, if you use it on a file with multiple Theora or Vorbis streams, it will generate incorrect fisbones for the second and subsequent streams of the type, as it hard codes the name and role
Instead, OggIndex should check which stream this is of a given type, and use that to assign sequential names (eg audio_1, audio_2) rather than hardcoded (eg audio_1 for everything), and flag subsequent streams of a type as alternate ones (rather than hard coded as the main one)https://gitlab.xiph.org/xiph/ogg/-/issues/2042ogg-index fails with an unhelpful error message if the file contains Speex or...2020-11-06T04:03:32ZNick Burchogg-index fails with an unhelpful error message if the file contains Speex or Opus streamsIf you try running ogg-index on a file which contains Opus or Speex streams (eg a Theora + Opus file), then you get a rather unfriendly error such as
`FAIL: Unhandled stream type, serialno=478384172 aborting indexing!`
Where the stream...If you try running ogg-index on a file which contains Opus or Speex streams (eg a Theora + Opus file), then you get a rather unfriendly error such as
`FAIL: Unhandled stream type, serialno=478384172 aborting indexing!`
Where the stream number is that of the Speex or Opus stream
Assuming it's not trivial to add support for those formats, it would be nice if ogg-index could instead give a more helpful message such as _Opus not supported (stream serialno=478384172) - aborting indexing! _https://gitlab.xiph.org/xiph/ogg/-/issues/2041ogg-index sets incorrect fisbone message header offset in the skeleton stream2020-11-06T04:05:16ZNick Burchogg-index sets incorrect fisbone message header offset in the skeleton streamAccording to http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt , in the skeleton fisbone,
> Offset to message header fields: 4 Byte unsigned integer that
> contains the number of Bytes used in this packet before t...According to http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt , in the skeleton fisbone,
> Offset to message header fields: 4 Byte unsigned integer that
> contains the number of Bytes used in this packet before the
> message header fields. For the version of the skeleton
> bitstream described in this document this number is fixed to 44.
The skeleton stream generated by things like ffmpeg2theora and speexenc set the message header offset to be 44, which is the position less the fisbone\0 header
However, ogg-index creates fisbones where the message header offset is 0x2c=52, which is the offset including the fisbone\0 header, which (based on the docs) seems to be incorrect
Note that it is only the offset that is wrong, the message headers start in the expected place at 44 bytes after the fisbone header / 52 bytes after the start of the fisbone packet datahttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/2040Low cpu usage with stdinpcm compared with alsa2018-10-05T08:40:13Zrajil.sLow cpu usage with stdinpcm compared with alsaI am using ices on a Raspberry Pi B+ model running raspbian. The audio is being fed through the attached usb radio tuner card.
#lsusb
Bus 001 Device 004: ID 06e1:a155 ADS Technologies, Inc. FM Radio Receiver/Instant FM Music (RDX-155-EF...I am using ices on a Raspberry Pi B+ model running raspbian. The audio is being fed through the attached usb radio tuner card.
#lsusb
Bus 001 Device 004: ID 06e1:a155 ADS Technologies, Inc. FM Radio Receiver/Instant FM Music (RDX-155-EF)
If i use alsa arecord and pipe to ices, the cpu usage is about 70%
arecord -D plughw:1 -r 48000 -c 2 -f S16_LE |ices2 /home/pi/ices-stdin.xml
However, if i use alsa directly within ices then the CPU shoots upto 100%
ICES version 2.0.1Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2039Icecast segfault : auth_url.c2018-03-06T12:49:47ZTeddyIcecast segfault : auth_url.cHi !
I'm using Icecast 2.4.0 with stream_auth authentication option.
When Nicecast (OSX streaming client) connects and sends metadata, a segfault occurs.
I investigated a bit, and it seems that _client->username_ and _client->password_...Hi !
I'm using Icecast 2.4.0 with stream_auth authentication option.
When Nicecast (OSX streaming client) connects and sends metadata, a segfault occurs.
I investigated a bit, and it seems that _client->username_ and _client->password_ (auth_url.c, lines 542/543) are both _null_.
My icecast.xml config file is almost genuine (changed the port, and configured a mountpoint with stream_auth). Please see attachments.
Here is a GDB run :
```
(gdb) run -c etc/icecast.xml
Starting program: /home/radioking/icecast-dbg/icecast-2.4.0/build/bin/icecast -c etc/icecast.xml
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7fda700 (LWP 16800)]
[New Thread 0x7ffff7f59700 (LWP 16801)]
[New Thread 0x7ffff7ed8700 (LWP 16802)]
[New Thread 0x7ffff14ca700 (LWP 16803)]
[New Thread 0x7ffff1449700 (LWP 16804)]
[Thread 0x7ffff1449700 (LWP 16804) exited]
[New Thread 0x7ffff083f700 (LWP 16805)]
[New Thread 0x7ffff07be700 (LWP 16806)]
[Thread 0x7ffff083f700 (LWP 16805) exited]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fda700 (LWP 16800)]
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: Aucun fichier ou dossier de ce type.
```
And the backtrace :
```
(gdb) bt
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x000000000040ba9c in util_url_escape (src=0x0) at util.c:269
#2 0x000000000041e0db in url_stream_auth (auth_user=<optimized out>)
at auth_url.c:542
#3 0x000000000041ac80 in stream_auth_callback (auth=0x64cf20, auth_user=0x684280)
at auth.c:248
#4 0x000000000041a5cf in auth_run_thread (arg=arg@entry=0x64cf20) at auth.c:311
#5 0x0000000000421e77 in _start_routine (arg=0x657550) at thread.c:657
#6 0x00007ffff68c4182 in start_thread (arg=0x7ffff7fda700) at pthread_create.c:312
#7 0x00007ffff65f130d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
```Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/vorbis/-/issues/2038Vorbis borks a pure 440Hz sine wave at the highest quality level2017-11-01T04:49:44ZArtem S. TashkinovVorbis borks a pure 440Hz sine wave at the highest quality levelA test case:
```
oggenc -q10 *wav
WARNING: quality setting too high, setting to maximum quality.
Opening with wav module: WAV file reader
Encoding "01_440hz Tone.wav" to
"01_440hz Tone.ogg"
at quality 10.00
[ 99.9%] [ 0...A test case:
```
oggenc -q10 *wav
WARNING: quality setting too high, setting to maximum quality.
Opening with wav module: WAV file reader
Encoding "01_440hz Tone.wav" to
"01_440hz Tone.ogg"
at quality 10.00
[ 99.9%] [ 0m00s remaining] /
Done encoding file "01_440hz Tone.ogg"
File length: 14m 42.0s
Elapsed time: 0m 09.2s
Rate: 95.4935
Average bitrate: 26.0 kb/s
```
Components versions:
```
$ rpm -qa | grep vorbis
libvorbis-1.3.4-2.el6.i686
libvorbis-devel-1.3.4-2.el6.i686
vorbis-tools-1.4.0-16.el6.i686
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2037Check if Icecast returns HTTP 200 on disallowed metadata updates2018-03-06T12:49:47ZThomas B. RückerCheck if Icecast returns HTTP 200 on disallowed metadata updatesWe've had a report that some version of Icecast might be doing this.
http://lists.xiph.org/pipermail/icecast/2014-August/012905.html
We should check if this is the case and if so consider changing it to a 403, accompanied by a sensible ...We've had a report that some version of Icecast might be doing this.
http://lists.xiph.org/pipermail/icecast/2014-August/012905.html
We should check if this is the case and if so consider changing it to a 403, accompanied by a sensible error message.Thomas B. RückerThomas B. Rücker