Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2019-04-19T11:32:52Zhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/594ices return value of 1 on successful startup2019-04-19T11:32:52ZGitlab Botices return value of 1 on successful startupint main in ices.c says it will end in ices_setup_shutdown by calling exit(0), however this
actually calls exit(1) <setup.c, line136>. This causes startup scripts that use the daemon
command within fedora core 1,2,3 and redhat 9 to rep...int main in ices.c says it will end in ices_setup_shutdown by calling exit(0), however this
actually calls exit(1) <setup.c, line136>. This causes startup scripts that use the daemon
command within fedora core 1,2,3 and redhat 9 to report a failure starting ices. I know it is
trivial, but it is very annoying in ices-0.4Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/593Tracking mountpoint bandwidth usage (from mailing list)2023-01-03T10:28:03ZAaron PaulleyTracking mountpoint bandwidth usage (from mailing list)Karl asked me to submit this to trac.xiph.org, from the mailing list.
I exclusively use mountpoints to setup my clients' streams. What would be absolutely amazing is if Icecast could log bandwidth usage per mountpoint, so I can better s...Karl asked me to submit this to trac.xiph.org, from the mailing list.
I exclusively use mountpoints to setup my clients' streams. What would be absolutely amazing is if Icecast could log bandwidth usage per mountpoint, so I can better see which mountpoints are using more or less of the bandwidth. I'm using mrtg to monitor the whole server, but it, and every stats program I've tried, has no way of differentiating the various mountpoints.
Thanks!Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/Infrastructure/-/issues/592no way to not select Milestone TheoraBeta12017-04-07T21:40:28ZGitlab Botno way to not select Milestone TheoraBeta1adding a new ticket to trac, there is no way to
not select Milestone TheoraBeta1, thats broken.adding a new ticket to trac, there is no way to
not select Milestone TheoraBeta1, thats broken.https://gitlab.xiph.org/xiph/icecast-server/-/issues/590Credits does not work2018-03-06T12:50:21ZGitlab BotCredits does not workHello
http://downloads.us.xiph.org/releases/icecast/icecast2_win32_2.2.0RC1_setup.exe
About -> Credits
does not work for me
WinXP Pro SP2 German;
AMD XP 2000+Hello
http://downloads.us.xiph.org/releases/icecast/icecast2_win32_2.2.0RC1_setup.exe
About -> Credits
does not work for me
WinXP Pro SP2 German;
AMD XP 2000+Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/theora/-/issues/589full Theora I decode support needed2007-08-30T19:09:38ZGhost Userfull Theora I decode support neededthe reference implementation does not support non-VP3 quant matricies or per-block qi switching. Support needs to be added to the reference decoder.the reference implementation does not support non-VP3 quant matricies or per-block qi switching. Support needs to be added to the reference decoder.https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/588Updated fr.po file2005-07-11T10:42:54ZGitlab BotUpdated fr.po fileUpdated fr.po file for vorbis-tools-1.0.1 (never used trac before, how can I
attach my patch ?)Updated fr.po file for vorbis-tools-1.0.1 (never used trac before, how can I
attach my patch ?)Manuel LoraManuel Lorahttps://gitlab.xiph.org/xiph/theora/-/issues/587finish libtheora api changes2007-11-07T08:03:57ZGitlab Botfinish libtheora api changesapi changes need to be finished for next theora releaseapi changes need to be finished for next theora releasehttps://gitlab.xiph.org/xiph/ogg/-/issues/586[PATCH] ogg2-arc does not compile wiht mingw322009-04-19T21:13:43Zj[PATCH] ogg2-arc does not compile wiht mingw32ogg2-arc from svn branches/ogg2-arc does not compile on mingw32,
since #include <_G_config.h> fails.
it should work as it is done in libogg/trunk - http://svn.xiph.org/trunk/ogg/include/ogg/os_types.h
```
# if defined(__CYGWIN__)
# ...ogg2-arc from svn branches/ogg2-arc does not compile on mingw32,
since #include <_G_config.h> fails.
it should work as it is done in libogg/trunk - http://svn.xiph.org/trunk/ogg/include/ogg/os_types.h
```
# if defined(__CYGWIN__)
# include <_G_config.h>
typedef _G_int64_t ogg_int64_t;
typedef _G_int32_t ogg_int32_t;
typedef _G_uint32_t ogg_uint32_t;
typedef _G_int16_t ogg_int16_t;
typedef _G_uint16_t ogg_uint16_t;
# elif defined(__MINGW32__)
typedef short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef long long ogg_int64_t;
typedef unsigned long long ogg_uint64_t;
```Arc RileyArc Rileyhttps://gitlab.xiph.org/xiph/vorbis/-/issues/583Compiling libvorbis-1.1.0 with gcc-4.0.0 causes bitrate / filesize increase2017-04-08T10:59:08ZGitlab BotCompiling libvorbis-1.1.0 with gcc-4.0.0 causes bitrate / filesize increase```
Using libvorbis-1.1.0 compiled with gcc-4.0.0 (20041107 snapshot) gives an
encoded file which is about 35% larger than the same file encoded using the same
libvorbis release but compiled with gcc-3.3.2. (For the gcc-4.0.0 version, I...```
Using libvorbis-1.1.0 compiled with gcc-4.0.0 (20041107 snapshot) gives an
encoded file which is about 35% larger than the same file encoded using the same
libvorbis release but compiled with gcc-3.3.2. (For the gcc-4.0.0 version, I
get around 270kbps for a -q6 encode). Other than the bitrate / filesize
increase, the encoded files sound the same.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/582[PATCH] Problem during book initialisation2017-04-08T10:58:44ZFelix Leder[PATCH] Problem during book initialisation```
The following situation can occur in _vds_shared_init (block.c) at line 224.
When calling vorbis_book_init_decode (sharedbook.c, l. 318) with a
static_codebook which has all lengthlist = 0, blocks with a size of 0 bytes are
allocated...```
The following situation can occur in _vds_shared_init (block.c) at line 224.
When calling vorbis_book_init_decode (sharedbook.c, l. 318) with a
static_codebook which has all lengthlist = 0, blocks with a size of 0 bytes are
allocated. The behaviour of malloc/calloc in that case is "implementation
dependant".
Most "implementations" return a pointer. Then everything works fine. BUT if you
have an implementation (e.g. TI DSPs) that returns NULL in case of a
calloc/malloc(0) either a segmentation fault is produced or data from memory
position 0 on is overwritten. Neither is wanted.
This overwriting happens in _book_unquantize (sharedbook.c, l. 183) in line 215
and possibly in line 235.
A fix is to replace lines 204 & 225 in this file:
< if((sparsemap && b->lengthlist[j]) || !sparsemap){
------------------
> if(b->lengthlist[j]){
This bug may be related to bug #340
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/581configure script ignores all the --with-ogg* options2017-04-08T10:58:44Zgorlikconfigure script ignores all the --with-ogg* options```
If there is a ogg version on the system configure will find it and ignore the --
with-ogg , --with-ogg-includes , --with-ogg-libraries options.
This prevents cross compiling on any system that has native ogg installed.
system detail...```
If there is a ogg version on the system configure will find it and ignore the --
with-ogg , --with-ogg-includes , --with-ogg-libraries options.
This prevents cross compiling on any system that has native ogg installed.
system details:
debian testing kernel 2.6.8-alpha and 2.6.9-i386
libvorbis-1.1.0
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/580divide by zero error2017-04-08T10:58:44Zjohnhdivide by zero error```
Encountered div by zero exception in bark_noise_hybridmp() in PSY.C caused by
the statement: D = tN * tXX - tX * tX; (don't know which one, there are 4
instances). When I prevented R = (A + x * B) / D; from being calculated if D ==
0...```
Encountered div by zero exception in bark_noise_hybridmp() in PSY.C caused by
the statement: D = tN * tXX - tX * tX; (don't know which one, there are 4
instances). When I prevented R = (A + x * B) / D; from being calculated if D ==
0, all was ok & the resultant OGG file could still be played (used winAmp).
Built v1.1 of ogg, vorbis, vorbisenc & vorbisfile with borland c++ builder v6 &
tested with builds of oggenc & oggdec on this dev. platform. Have emailed the
offending WAV file to Mike Smith - was generated by using directSound (v9) audio
capture api. Problem also occurred on a WAV decoded from an MP3 using LAME.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/578Encoding large number of files in one go crashes system2007-06-17T08:51:57ZGitlab BotEncoding large number of files in one go crashes system```
I am running Windows XP with Service Pack 2 and the Vorbis 1.0.1 Tools.
When I was trying to run a large batch query converting standard WAV files (14
GB in 255 Files (21 CDs) in a single directory) to Vorbis using OggDropXP
(Qual...```
I am running Windows XP with Service Pack 2 and the Vorbis 1.0.1 Tools.
When I was trying to run a large batch query converting standard WAV files (14
GB in 255 Files (21 CDs) in a single directory) to Vorbis using OggDropXP
(Quality: 6, no special options), the whole system reproducibly froze (3x) after
approximately 1 GB of source data had been processed.
Suspecting OggDrop, I generated a batch file that individually called oggenc for
each one of the remaining 200 files. Running the batch file in turn reproducibly
led (4x) to a blue screen (IRQL_NOT_LESS_OR_EQUAL variety). The crash once again
occured after about 1 GB of source data.
I have just finished encoding all files by dropping the remaining 100 files into
OggDrop *one CD at a time* without incident.
I do not think that the actual file content has anything to do with the problem,
as the files affected by crashes were all handled without problems when I
subsequently resumed encoding with the exact same file.
My system is stable and I think I can rule out completely unrelated causes for
the crashes, which occurred exactly, and only, when I used OggDrop/OggEnc. I had
extensively used OggDrop before without any problems, but only for one CD at a
time.
Of course, it is possible or even probable that the actual fault does not lie
with OggEnc/OggDrop, but the Windows Kernel/Explorer and was merely triggered
through the interaction with OggEnc. Still, I find my system's behavior quite
bizarre. While I could at least in principle imagine how a large number of files
could crash OggDrop, I have no idea why OggEnc should be affected by being run
50 times in a row.
I know this bug report is only partially helpful - if I can reproduce the blue
screen one more time, I will add the detailed information (especially which
module caused it).
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/577[PATCH] segfault in ov_time_seek()2017-04-08T10:59:27Zi.danihelka[PATCH] segfault in ov_time_seek()```
There seems to be bug in libvorbisfile.
The bug is in lib/vorbisfile.c in function ov_time_seek().
The variable "link" can have value -1 when is passed to expression
"vf->vi[link].rate".
The for cycle ends when (link == -1) or (seco...```
There seems to be bug in libvorbisfile.
The bug is in lib/vorbisfile.c in function ov_time_seek().
The variable "link" can have value -1 when is passed to expression
"vf->vi[link].rate".
The for cycle ends when (link == -1) or (seconds >= time_total).
This could leaves variable link with value -1.
This happends when functions is called with seconds = 0.0
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/572alloca() is not portable2017-04-08T10:58:44Zjohnathanalloca() is not portable```
All calls to function "alloca()" should be removed as this function is machine
specific and not supported on all platforms or all compilers (ie. MPW for
Macintosh does not support this functionality). Even the man page for alloca()
...```
All calls to function "alloca()" should be removed as this function is machine
specific and not supported on all platforms or all compilers (ie. MPW for
Macintosh does not support this functionality). Even the man page for alloca()
states that use of this function is inadvisable.
Thanks.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/speex/-/issues/571speex.m4 : syntax error2018-01-21T13:05:27ZGitlab Botspeex.m4 : syntax error```
autoconf 1.8 is stricter than older revisions. it warns about a syntax error :
/usr/share/aclocal/speex.m4:10: warning: underquoted definition of XIPH_PATH_SPEEX
AC_DEFUN(XIPH_PATH_SPEEX, => AC_DEFUN([XIPH_PATH_SPEEX],
would fix i...```
autoconf 1.8 is stricter than older revisions. it warns about a syntax error :
/usr/share/aclocal/speex.m4:10: warning: underquoted definition of XIPH_PATH_SPEEX
AC_DEFUN(XIPH_PATH_SPEEX, => AC_DEFUN([XIPH_PATH_SPEEX],
would fix it
```Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/speex/-/issues/570speex header location, .pc file and backward compatibility2018-01-21T13:05:27ZGitlab Botspeex header location, .pc file and backward compatibility```
trying to compile gstreamer speex plug-in with speex 1.1.6, i had the bad
experience to see that headers were moved.
the good point was that now speex uses a .pc file
the bad point is that the include path in it is bad
in order tha...```
trying to compile gstreamer speex plug-in with speex 1.1.6, i had the bad
experience to see that headers were moved.
the good point was that now speex uses a .pc file
the bad point is that the include path in it is bad
in order that program using speex won't have to change all their includes but
only their configure.ac file, it should be better to change the following :
Cflags: -I${includedir} => Cflags: -I${includedir}/speex
i suppose it is the same for speex 1.0.4 (i did not check this one)
```Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/568oggenc jumbles -N and -n2018-01-22T04:56:57Zwhitewolf_foxoggenc jumbles -N and -n```
Hi Vorbis Team!
When defining the tracknumber, oggenc shall set to a new file, you're using the
"-N #" trigger.
When defining a naming string, containing the track's number, oggenc uses "%n".
Thats confusing.
My opinion is, that yo...```
Hi Vorbis Team!
When defining the tracknumber, oggenc shall set to a new file, you're using the
"-N #" trigger.
When defining a naming string, containing the track's number, oggenc uses "%n".
Thats confusing.
My opinion is, that you should change the usage of "-N" and "-n" to "-N" for
defining a nameing string and "-n" to define the tracknumber. Further, you
should change "-G" to "-g". This prevents from doing mistakes caused by using
incorrect triggers, because ALL taging related switches are consistent lower case.
As an alternative you should make "%N" an valid naming string character.
MfG
Marc Richter
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/567Icecast2 W32 Forms Client -> Windows Service2018-03-06T12:50:21ZjasonrIcecast2 W32 Forms Client -> Windows Service```
I think it makes sense to run the Icecast2 server as a Windows Service in this
environment as opposed to my current workaround as having it run as an alway
logged-in underprivilaged account under terminal services on Windows Server...```
I think it makes sense to run the Icecast2 server as a Windows Service in this
environment as opposed to my current workaround as having it run as an alway
logged-in underprivilaged account under terminal services on Windows Server
2003.
Same goes for ezstream, of course. =)
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/566Freeze/infinite loop on old test file2017-04-08T10:59:27ZkcarnoldFreeze/infinite loop on old test file```
I found the attached file among some old experimentation I was doing with
peeling. (Actually, the original was larger, but 20k of it was enough to
trigger the problem.) I tried to play it with ogg123, but it hits an infinite
loop ...```
I found the attached file among some old experimentation I was doing with
peeling. (Actually, the original was larger, but 20k of it was enough to
trigger the problem.) I tried to play it with ogg123, but it hits an infinite
loop (in ov_open, I'll guess, from where it stopped). ogginfo says:
Negative granulepos on vorbis stream outside of headers. This file was created
by a buggy encoder
I'm marking this "major" because it happens reliably with such small data.
Hopefully it's reproducable on others' systems; if not, I can help debug. This
is the vorbis-tools Debian package, though, and it works very reliably on
everything else.
```Monty MontgomeryMonty Montgomery