Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-08-03T06:12:52Zhttps://gitlab.xiph.org/xiph/ezstream/-/issues/1240ezstream crashes (seg fault) if given an empty playlist (.m3u)2017-08-03T06:12:52ZGitlab Botezstream crashes (seg fault) if given an empty playlist (.m3u)"ezstream -c music.xml" with the following config file:
<ezstream>
<url>http://xxx:8000/music.mp3</url>
<sourcepassword>xxx</sourcepassword>
<format>MP3</format>
<filename>music.m3u</filename>
<svrinfoname>Music</svr..."ezstream -c music.xml" with the following config file:
<ezstream>
<url>http://xxx:8000/music.mp3</url>
<sourcepassword>xxx</sourcepassword>
<format>MP3</format>
<filename>music.m3u</filename>
<svrinfoname>Music</svrinfoname>
<svrinfourl>http://xxx</svrinfourl>
<svrinfogenre>Classical</svrinfogenre>
<svrinfodescription>Music</svrinfodescription>
<svrinfobitrate>64</svrinfobitrate>
<svrinfoquality>4.0</svrinfoquality>
<svrinfochannels>2</svrinfochannels>
<svrinfosamplerate>24000</svrinfosamplerate>
<svrinfopublic>1</svrinfopublic>
</ezstream>
...where the file "music.m3u" is empty (0 bytes long), causes ezstream 0.4.3 to crash with a segmentation fault.
Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/ezstream/-/issues/1225ezstream 0.4.0 do not send ID3 tags to icecast2 v2.3.12017-08-03T06:12:53Zmatpocezstream 0.4.0 do not send ID3 tags to icecast2 v2.3.1Here is the post from http://icecast.imux.net/viewtopic.php?t=3246
I compiled ezstream 0.4.0 on FreeBSD and surprised that it do not send ID3 tags to icecast2 v2.3.1. I tried both variants with and without taglib. ezstream streams a pla...Here is the post from http://icecast.imux.net/viewtopic.php?t=3246
I compiled ezstream 0.4.0 on FreeBSD and surprised that it do not send ID3 tags to icecast2 v2.3.1. I tried both variants with and without taglib. ezstream streams a playlist that contains only MP3 files without reencoding, config based on example ezstream_mp3.xml.
Old ezstream 0.2.1 normally sends ID3 tags to icecast2 2.3.1.
I run ezstream in verbose mode - ezstream reading tags from mp3 files:
```
> ezstream -vv -c /usr/local/etc/ezstream.xml
ezstream: Connected to http://localhost:8000/radio
ezstream: Streaming ``Some Artist - Goodnight Tonight '' (file: /mnt/mp3/foreign/Rock/Some Artist/Gold singles collection/track_15.mp3)
```
Another notice - ezstream do not strip extra spaces from ID3 tag.
There is 2 acknowledgments of this bug at the forum thread.Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2190ezstream (libshout?) hangs while streaming the attached mp32017-11-16T12:06:13Zjakebriggsezstream (libshout?) hangs while streaming the attached mp3ezstream (libshout?) hangs while streaming the attached mp3. Using advanced debugging techniques (printf's, everywhere, a forest of printf's) I've made my way down to the function shout_send in libshout - specifically I think this never ...ezstream (libshout?) hangs while streaming the attached mp3. Using advanced debugging techniques (printf's, everywhere, a forest of printf's) I've made my way down to the function shout_send in libshout - specifically I think this never returns:
```
return self->send(self, data, len);
```
but my advanced debugging techniques ran out of steam here.... I might have a play with gdb but I've never played with that before....Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/vorbis/-/issues/626Extreme low bitrates 32khz 32kbits (technical brief complaint :))2017-04-08T10:59:08ZGitlab BotExtreme low bitrates 32khz 32kbits (technical brief complaint :))I had an error when I tried compressing a .wav file to .ogg using 32kbps average bitrate. It seems .ogg isn't capable of compressing at very low (streaming) bitrates.
I wanted to compare .ogg to it's rival .wma
I know .wma is not the bes...I had an error when I tried compressing a .wav file to .ogg using 32kbps average bitrate. It seems .ogg isn't capable of compressing at very low (streaming) bitrates.
I wanted to compare .ogg to it's rival .wma
I know .wma is not the best codec in higher bitrates (64kbps and beyond); but it is untill now my best codec for the lower bitrates; 56Kbps & below.
It has by far surpassed mp3, and even mp4 on these low bitrates; with a peakquality/compression at 32Kbps/32Khz stereo (which is WMA's best quality/compression ratio) if you don't believe, try any sample out and compare it to MP3's 32Kbits-32khz stereo version, and you will see (or hear).
I heard btw real and wma, and compared them as well; And I'm sad to say, that wma is much better then real, since it uses a way more advanced stereoimage while real has the tendency to make sound appear in the center even when it is slightly panned.
=> I believe REAL has an extreme bad virtual soundfield in the lower bitrates; almost anything sounds mono, if you get what I mean.
Also wma uses better low frequencies. There where real seems to cut off low frequencies, wma keeps it.
Also the highfrequencies sounds better to me (which is a pure sense of taste).
If cymbals would resound, wma sounds artificial, and real's sound will be closer to the original, I agree on that; but on very low bitrates (32kbits-32Khz) the hissing of taperecordings, or high frequencies resounding through a song, like cymbals, will sound much more stable then mp3 or real sound. While with mp3 and real, you hear a fluxuating of the high frequency cut-off, WMA seems to keep a stable cuttoff, which is better for the ear.
This same phenomenon is there when comparing Fraunhofer's MP3 with Lame's.
On exactly the same settings, Lame's codec encodes the high frequencies slightly better then the Fraunhofer one; Only,
The Lame's codec fluxuates more, then fraunhofer.
Which results in Lame giving more clear, and brighter sound, while Fraunhofer gives more stable, almost dry sound.
I personally would prefer lame above the other, but on my AMD, lame encodes at an average of 7 to 8x; while Fraunhofer encodes at 24x
Also with playback, lame decoding require 3% more of CPU power, then Fraunhofer's.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/467Extraneous 'f' parameter in ov_open_callbacks documentation2020-06-13T00:42:20ZmatExtraneous 'f' parameter in ov_open_callbacks documentation```
The docs look quite good, but I noticed one minor error.
There is no parameter 'f' to ov_open_callbacks, but it is documented
in http://www.xiph.org/ogg/vorbis/doc/vorbisfile/ov_open_callbacks.html
I think this is just a cut-and-pas...```
The docs look quite good, but I noticed one minor error.
There is no parameter 'f' to ov_open_callbacks, but it is documented
in http://www.xiph.org/ogg/vorbis/doc/vorbisfile/ov_open_callbacks.html
I think this is just a cut-and-paste error from the ov_open docs.
'datasource' needs to be documented instead.
As a minor nit, the documentation also talks about calling 'fclose' on
the file pointer, which is not necessarily appropriate for ov_open_callbacks.
I am using ov_open_callbacks because my data is not coming from a FILE *.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/670Extend slave mechanism to allow for multiple master servers.2018-03-06T12:50:21ZGitlab BotExtend slave mechanism to allow for multiple master servers.Extend slave mechanism to allow for multiple master servers so that the slave can relay from several master icecast servers.Extend slave mechanism to allow for multiple master servers so that the slave can relay from several master icecast servers.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/opus/-/issues/1894exp_analysis doesn't work in fixed-point2018-11-26T18:44:40ZJean-Marc Valinexp_analysis doesn't work in fixed-pointThe exp_analysis branch added some float operations that need to be converted to fixed-point or #ifdef'ed out.The exp_analysis branch added some float operations that need to be converted to fixed-point or #ifdef'ed out.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/2358Excessive noise generated by CELT PLC2021-06-24T16:30:44ZFrancis QuiersExcessive noise generated by CELT PLCWe recently came across a situation where bursty loss resulted in relatively loud noise in output of the Opus decoder.
The previous frames (before the gap) were all encoded as CELT, and since the gap was more than 5 frames, the noise-ba...We recently came across a situation where bursty loss resulted in relatively loud noise in output of the Opus decoder.
The previous frames (before the gap) were all encoded as CELT, and since the gap was more than 5 frames, the noise-based CELT PLC eventually got triggered (because of [this piece of logic](https://gitlab.xiph.org/xiph/opus/-/blob/v1.3.1/celt/celt_decoder.c#L531)), and this is when the noise starts.
The problem can be reproduced using the following branch, which is based on tag v1.3.1, plus an extra option in `opus_demo` in order to be able to feed a stream that does not include the "final range" check, but only each packet's length (or 0 for a lost packet) followed by the opus data:
https://gitlab.xiph.org/cisquiers/opus/-/tree/opus_demo_support_for_decoding_external_streams
The commands to run are the following:
```
./autogen.sh
./configure --enable-fixed-point
make
./opus_demo -d 48000 1 -external_stream stream.opus output.pcm
```
Input stream:
[stream.opus](/uploads/92e308f2c6374561db59e63ee5e967e8/stream.opus)
Output raw audio (mono, 16-bit, little-endian, 48kHz):
[output.pcm](/uploads/28f3afc3cf62f57df76f0c951f2feb82/output.pcm)
Note that I tried to reproduce the problem by starting from raw audio (either using silence, or a small negative DC as what the stream decodes to prior to the gap) and encoding it using `opus_demo`, but I wasn't unable to do so.
Unfortunately I don't have access to the original raw audio, or the source code for the client that generated this stream.
I cannot actually guarantee that the encoder that was used was a vanilla Opus release, without any custom modification that could perhaps have generated this (perhaps slightly unusual?) bitstream (particularly the DC offset). However, since the bitstream appears to be valid, perhaps the CELT decoder should still not generate such a noise in output in this case.https://gitlab.xiph.org/xiph/oggdsf/-/issues/1516EXCEPTION_INT_DIVIDE_BY_ZERO occurs in libOOOGG when encoding2009-02-27T03:17:32ZJerry WangEXCEPTION_INT_DIVIDE_BY_ZERO occurs in libOOOGG when encodingThis problem has been fazing me for a while.
I am working with the latest binaries, version 0.81.15562, 2008-12-06. downloaded from http://downloads.xiph.org/releases/oggdsf/oggcodecs_0.81.15562-win32.exe
I am writing some stuff to con...This problem has been fazing me for a while.
I am working with the latest binaries, version 0.81.15562, 2008-12-06. downloaded from http://downloads.xiph.org/releases/oggdsf/oggcodecs_0.81.15562-win32.exe
I am writing some stuff to convert audio files into ogg format by using DirectShow Filters.
For example. The filter is connected as:
Files --> MEPG Spliter --> MEPG DECODER --> Audio Resampler Filter --> Vorbis Encoder Filter --> OGG Mux Filter
If I launch the exe in VisualStudio, everything works correctly.
If I launch the exe not in debug mode,(by clicking), it will crash.
Then I found that: an *EXCEPTION_INT_DIVIDE_BY_ZERO* exception will threw from libOOOGG. If the debugger ignores this exception and continue, everyting works and keep find. Otherwise, the whole process will crash.
I will post more details below
=========================
When exception threw out, a Dialog box will show:
```
Unhandled exception at 0x01366f9b in AudioFormatConvertorD.exe: 0xC0000094: Integer division by zero.
```
Then look into the stack trace window.
```
> libOOOgg.dll!01366f9b() *<-- crash here!!!*
[Frames below may be incorrect and/or missing, no symbols loaded for libOOOgg.dll]
libOOOgg.dll!0136222f()
libOOOgg.dll!0136217a()
libOOOgg.dll!01364df7()
libOOOgg.dll!01362354()
libOOOgg.dll!01364ea8()
libOOOgg.dll!013649d9()
libOOOgg.dll!01361fc0()
libOOOgg.dll!01365670()
libOOOgg.dll!01365875()
libOOOgg.dll!0136578a()
libOOOgg.dll!0136544b()
dsfOggMux.dll!013a39fc()
dsfOggMux.dll!013a6bd2()
dsfVorbisEncoder.dll!01328da2()
dsfVorbisEncoder.dll!01322e90()
dsfVorbisEncoder.dll!013228a6()
dsfVorbisEncoder.dll!0132478b()
```
================
OK, now I must ignore this exception by writing my own debugger.
```
STARTUPINFO stInfo = {0};
stInfo.cb = sizeof(stInfo);
PROCESS_INFORMATION stProcInfo = {0};
BOOL bRet = ::CreateProcess( NULL
, strCmdLine.GetBuffer()
, NULL
, NULL
, FALSE
, 0
, NULL
, g_oApp.GetModulePath()
, &stInfo
, &stProcInfo
);
strCmdLine.ReleaseBuffer();
DWORD dwContinueStatus = DBG_CONTINUE;
BOOL bExit = FALSE;
while(!bExit)
{
DEBUG_EVENT stDebugEvt = {0};
::WaitForDebugEvent(&stDebugEvt, INFINITE);
switch (stDebugEvt.dwDebugEventCode)
{
case EXCEPTION_DEBUG_EVENT:
switch(stDebugEvt.u.Exception.ExceptionRecord.ExceptionCode)
{
case EXCEPTION_INT_DIVIDE_BY_ZERO:
dwContinueStatus = DBG_CONTINUE; // <-- ignore
break;
default:
break;
}
break;
case LOAD_DLL_DEBUG_EVENT:
CloseHandle(stDebugEvt.u.LoadDll.hFile);
break;
case CREATE_PROCESS_DEBUG_EVENT :
CloseHandle(stDebugEvt.u.CreateProcessInfo.hFile);
break;
case EXIT_PROCESS_DEBUG_EVENT:
bExit = TRUE;
break;
default:
dwContinueStatus = DBG_CONTINUE;
break;
}
::ContinueDebugEvent( stDebugEvt.dwProcessId, stDebugEvt.dwThreadId, dwContinueStatus);
}
```
=====================
I can repeat this problem in both of my Win2K3 PCs.
OS Windows 2003 R2(SP2) and upgraded by "Windows Update".
The CPU on my first PC is Intel Pentium D.
The other CPU on my 2nd PC is Inter Core2 E6300.
Cristian AdamCristian Adamhttps://gitlab.xiph.org/xiph/theora/-/issues/1293examples should use new API2010-02-01T21:06:34ZGitlab Botexamples should use new APIdump_video.c, player_example.c should be updated with that on theora-exp using the new API.
Note, however, that dump_video from theora-exp it's slower than current dump_video. Current dump_video also prints theora comment header, and se...dump_video.c, player_example.c should be updated with that on theora-exp using the new API.
Note, however, that dump_video from theora-exp it's slower than current dump_video. Current dump_video also prints theora comment header, and seems to have other fixes over theora-exp (the same for player_example).https://gitlab.xiph.org/xiph/vorbis/-/issues/134examples don't compile with C902017-04-08T10:58:44Zpapadopoexamples don't compile with C90```
Hi,
I suggest you use C90 /**/ comments instead of C99 // comments so that
vorbis compiles on older UNIX which lack a C99 compiler. Using the Sun
Workshop 5.0 compiler:
gmake[1]: Entering directory `/tmp/libvorbis-1.0rc3/examples'
...```
Hi,
I suggest you use C90 /**/ comments instead of C99 // comments so that
vorbis compiles on older UNIX which lack a C99 compiler. Using the Sun
Workshop 5.0 compiler:
gmake[1]: Entering directory `/tmp/libvorbis-1.0rc3/examples'
[..]
cc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0rc3\" -DHAVE_DLFCN_H=1
-DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_SQRTF=1 -I. -I. -I../include
-I/usr/local/libogg/include -xO4 -fast -w -fsimple -native -xcg92 -fast
-DUSE_MEMORY_H -c encoder_example.c
"encoder_example.c", line 100: syntax error before or at: /
cc: acomp failed for encoder_example.c
```Segher BoessenkoolSegher Boessenkoolhttps://gitlab.xiph.org/xiph/vorbis/-/issues/491example code error?2020-06-23T16:36:31ZBill Nottinghamexample code error?```
Originally filed in Red Hat's bugzilla by d.binderman@virgin.net:
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Description of problem:
I just tried to compile package libvorbis-1_0-8 from Fedora...```
Originally filed in Red Hat's bugzilla by d.binderman@virgin.net:
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Description of problem:
I just tried to compile package libvorbis-1_0-8 from Fedora.
The compiler said
1.
seeking_example.c(142): remark #592: variable "pos" is used before
its value is set
seeking_example.c(163): remark #592: variable "pos" is used before
its value is set
seeking_example.c(190): remark #592: variable "pos" is used before
its value is set
I've checked the source code, and I agree with the compiler. This
code would benefit from rework.
Version-Release number of selected component (if applicable):
libvorbis-1_0-8
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2189Event triggers for Icecast 2.52019-01-22T06:35:22ZThomas B. RückerEvent triggers for Icecast 2.5We are introducing event triggers and need to decide what we trigger on. Currently already supported:
* source-connect
* source-disconnect
* icecast-start
* icecast-stop
Proposed additional triggers:
* client-connect (all connectio...We are introducing event triggers and need to decide what we trigger on. Currently already supported:
* source-connect
* source-disconnect
* icecast-start
* icecast-stop
Proposed additional triggers:
* client-connect (all connections that are !SOURCE|!PUT)
* client-disconnect (all connections that are !SOURCE|!PUT)
* icecast-reload (configuration reload as caused SIGHUP or web request)
* yp-failure
* metadata-change (Both in container and side-channel triggered, with differentiating field)
* various admin commands (Including authentication management)
* critical errors or even general logging (this needs to be thought through)Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2233Escape mount string in metadata in libshout (or allow user to specify a diffe...2018-06-16T21:36:01ZKevin WernEscape mount string in metadata in libshout (or allow user to specify a different string)In shout.c, the same string is used for both the mountpoint in the metadata URI and the mountpoint itself. This causes an issue when the string contains characters that could be parsed incorrectly (i.e. a URI with a querystring), because...In shout.c, the same string is used for both the mountpoint in the metadata URI and the mountpoint itself. This causes an issue when the string contains characters that could be parsed incorrectly (i.e. a URI with a querystring), because the mountpoint specified in the metadata no longer correlates to the mountpoint that was created. In our case, we have a string that needs to be escaped in the metadata URI only.
I was thinking shout_t could have a separate property for the metadata mount string (and a corresponding setter the user could call), and if it isn't set when shout_set_metadata() is called, then the function uses the original mount property.
Another solution to our problem specifically would always escaping the single mount string for the metadata string, but I think the solution above is more general. (Think, for instance, if a user wanted to send querystring parameters with the SOURCE call, but truncate it to just the resource in the metadata)
I could write a quick patch for either, but I wanted to get your input first.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/111Errors in the man page for oggenc2006-06-12T11:04:47ZreaperErrors in the man page for oggenc```
The man page for oggenc has a few errors -
1. The header still says "Release candidate 2" instead of "Release candidate 3"
2. The BUGS section lists -m -M and -q as non-implemented options. They are
implemented in RC3
``````
The man page for oggenc has a few errors -
1. The header still says "Release candidate 2" instead of "Release candidate 3"
2. The BUGS section lists -m -M and -q as non-implemented options. They are
implemented in RC3
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/738Errorcode when client wants to connect to "full" mountpoint should be changed2020-10-15T13:51:17ZrobeErrorcode when client wants to connect to "full" mountpoint should be changedHi,
the errorcode that clients receive when they want to connect to a mountpoint which has reached its maxlisteners limit should be changed from the current "404 File Not Found" to something more meaningful, since this is the same error...Hi,
the errorcode that clients receive when they want to connect to a mountpoint which has reached its maxlisteners limit should be changed from the current "404 File Not Found" to something more meaningful, since this is the same errorcode that gets returned when the requested mountpoint doesn't exist.
A possible solution to this would be returning 403 with a customized reason phrase like "Mountpoint full" (or similar) in the header (since this is the only thing (if any) that gets forwarded to the user with most clients). The HTTP 1.1 RFC (#2616) allows this:
6.1.1:
[..]
The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only
recommendations -- they MAY be replaced by local equivalents without
affecting the protocol.
[..]Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/vorbis/-/issues/1520Error playing file - Ogg Vorbis Mode 2 (6750)2019-07-01T08:51:48ZluyError playing file - Ogg Vorbis Mode 2 (6750)I keep getting errors playing back files that were encrypted with Vorbis.
MediaInfo report:
General
Complete name : C:\RT120307-0938.wav
Format : Wave
File size : 49.6...I keep getting errors playing back files that were encrypted with Vorbis.
MediaInfo report:
General
Complete name : C:\RT120307-0938.wav
Format : Wave
File size : 49.6 MiB
Duration : 1h 48mn
Overall bit rate : 64.0 Kbps
Audio
Format : Vorbis
Format settings, Floor : 1
Codec ID : 6750
Codec ID/Info : Mode 2
Duration : 1h 48mn
Bit rate : 64.0 Kbps
Channel(s) : 1 channel
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 49.5 MiB (100%)
Writing library : libVorbis 1.0 RC3 (UTC 2001-12-31)
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1519Error playing file - Ogg Vorbis Mode 2 (6750)2019-07-01T08:51:48ZluyError playing file - Ogg Vorbis Mode 2 (6750)I keep getting errors playing back files that were encrypted with Vorbis.
MediaInfo report:
General
Complete name : C:\RT120307-0938.wav
Format : Wave
File size : 49.6...I keep getting errors playing back files that were encrypted with Vorbis.
MediaInfo report:
General
Complete name : C:\RT120307-0938.wav
Format : Wave
File size : 49.6 MiB
Duration : 1h 48mn
Overall bit rate : 64.0 Kbps
Audio
Format : Vorbis
Format settings, Floor : 1
Codec ID : 6750
Codec ID/Info : Mode 2
Duration : 1h 48mn
Bit rate : 64.0 Kbps
Channel(s) : 1 channel
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 49.5 MiB (100%)
Writing library : libVorbis 1.0 RC3 (UTC 2001-12-31)
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1518Error playing file - Ogg Vorbis Mode 2 (6750)2019-07-01T08:51:48ZluyError playing file - Ogg Vorbis Mode 2 (6750)I keep getting errors playing back files that were encrypted with Vorbis.
MediaInfo report:
General
Complete name : C:\RT120307-0938.wav
Format : Wave
File size : 49.6...I keep getting errors playing back files that were encrypted with Vorbis.
MediaInfo report:
General
Complete name : C:\RT120307-0938.wav
Format : Wave
File size : 49.6 MiB
Duration : 1h 48mn
Overall bit rate : 64.0 Kbps
Audio
Format : Vorbis
Format settings, Floor : 1
Codec ID : 6750
Codec ID/Info : Mode 2
Duration : 1h 48mn
Bit rate : 64.0 Kbps
Channel(s) : 1 channel
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 49.5 MiB (100%)
Writing library : libVorbis 1.0 RC3 (UTC 2001-12-31)
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1889Error pages needs update2018-03-06T12:49:48ZPhilipp SchafftError pages needs updateThe error pages generated by icecast are currently hardcoded. Some contain invalid HTML.
Please provide a valid but very simple HTML file for the HTTP errors 400 and 404. I will also take such error pages for 401 and 403 but that has le...The error pages generated by icecast are currently hardcoded. Some contain invalid HTML.
Please provide a valid but very simple HTML file for the HTTP errors 400 and 404. I will also take such error pages for 401 and 403 but that has less priority.
The pages (except for 401) all take an string telling the user about the error. Please just leave '%s' in the 'template' where it should go.
current pages look like this:
```
<b>%s</b>
```Icecast 2.4.0Thomas B. RückerThomas B. Rücker