Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2019-04-19T11:32:53Zhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/276Ices leaks memory after losing connection(s) to icecast2019-04-19T11:32:53ZgshangIces leaks memory after losing connection(s) to icecast```
We run ices2 with three seperate streams - one unchanged, one a quality 0
circa 64kbps stream, and the other a quality -1 22khz mono stream. It
seems that when cron.daily runs, one or more of these streams will lose
connectivity wit...```
We run ices2 with three seperate streams - one unchanged, one a quality 0
circa 64kbps stream, and the other a quality -1 22khz mono stream. It
seems that when cron.daily runs, one or more of these streams will lose
connectivity with the icecast2 server (which is running on another box).
The number of streams dropped varies from day to day. After this point,
it appears that ices leaks memory until it eventually runs out of memory
and is killed by the kernel.
To illustrate this, here's a ps -aux from when ices was started yesterday
afternoon (US time):
kirk 8589 0.1 1.5 11376 3876 tty3 S 16:23 0:00 ../ices
egoplay.xml
kirk 8591 0.0 1.5 11376 3876 tty3 S 16:23 0:00 ../ices
egoplay.xml
kirk 8592 13.6 1.5 11376 3876 tty3 S 16:23 0:04 ../ices
egoplay.xml
kirk 8593 0.0 1.5 11376 3876 tty3 S 16:23 0:00 ../ices
egoplay.xml
kirk 8594 4.8 1.5 11376 3876 tty3 S 16:23 0:01 ../ices
egoplay.xml
These are pretty typical of what it looked like prior to the streams being
disconnected at 01:01 this morning. Here's what it looked like at about
03:42:
kirk 8589 0.0 69.2 185692 177352 ? S Oct31 0:01 ../ices
egoplay.xml
kirk 8591 0.0 69.2 185692 177352 ? S Oct31 0:00 ../ices
egoplay.xml
kirk 8592 16.8 69.2 185692 177352 ? R Oct31 114:23 ../ices
egoplay.xml
kirk 8593 6.1 69.2 185692 177352 ? R Oct31 41:58 ../ices
egoplay.xml
kirk 8594 9.6 69.2 185692 177352 ? R Oct31 65:16 ../ices
egoplay.xml
And here's what it looked like just before Kirk killed it off just before
6Am:
kirk 8589 0.0 80.1 320268 205368 ? S Oct31 0:03 ../ices
egoplay.xml
kirk 8591 0.0 80.1 320268 205368 ? S Oct31 0:00 ../ices
egoplay.xml
kirk 8592 18.3 80.1 320268 205368 ? R Oct31 149:13 ../ices
egoplay.xml
kirk 8593 9.4 80.1 320268 205368 ? R Oct31 76:49 ../ices
egoplay.xml
kirk 8594 12.3 80.1 320268 205368 ? R Oct31 100:08 ../ices
egoplay.xml
Left to its own devices, it would have run out of memory.
The logs don't say a lot. The ices log says nothing, really. The only
pointer that something's gone wrong is the fact that the encoder and
resample initialisations stop appearing in the log with each song. The
songs continue to be printed, however.
the icecast error log seems to indicate that the source just died at the
other end.
[2002-11-01 01:01:40] WARN source/source_main Disconnecting source:
socket timeout (10 s) expired
[2002-11-01 01:01:40] INFO source/source_main Removing source following
disconnection
[2002-11-01 01:01:40] DBUG source/source_main Source exiting
[2002-11-01 01:01:40] WARN source/source_main Disconnecting source:
socket timeout (10 s) expired
[2002-11-01 01:01:40] INFO source/source_main Removing source following
disconnection
[2002-11-01 01:01:40] DBUG source/source_main Source exiting
[2002-11-01 01:01:40] WARN source/source_main Disconnecting source:
socket timeout (10 s) expired
[2002-11-01 01:01:40] INFO source/source_main Removing source following
disconnection
[2002-11-01 01:01:40] DBUG source/source_main Source exiting
This has been happening consistantly since I first wrote about it on the
9th of October.
http://www.xiph.org/archives/icecast/3367.html
http://www.xiph.org/archives/icecast/3401.html
This is with current CVS ices and libshout2.
What I speculate is happening is that, for whatever reason, probably due
to system load with updatedb or sometihng, one or more streams lose their
connection with icecast. Despite the settings in the icex XML config, no
attempts are made to reconnect, acording to all of the logs. So some part
of ices seems to think that they're still connected.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/275MacOS X CD Audio encoding support2002-11-07T12:23:40ZjordyMacOS X CD Audio encoding support```
MacOS X's internal CD Audio file system format is a little-endian variant of
AIFF-C. A small patch is needed to properly handle it.
``````
MacOS X's internal CD Audio file system format is a little-endian variant of
AIFF-C. A small patch is needed to properly handle it.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/273[PATCH] vorbiscomment - newline quoting patch - multi-line comment round-trip...2009-04-19T20:17:11Zcben[PATCH] vorbiscomment - newline quoting patch - multi-line comment round-tripping```
See the linked mail and the patch - they have the details.
Basically this allows to round-trip multi-line comments and
even read comments with null bytes (but not write them, see
mail for details). If the two styles are overkill in ...```
See the linked mail and the patch - they have the details.
Basically this allows to round-trip multi-line comments and
even read comments with null bytes (but not write them, see
mail for details). If the two styles are overkill in your
opinion, the `255' one can be removed.
I also updated some unrelated small details in the manpage
```IvoIvohttps://gitlab.xiph.org/xiph/vorbis/-/issues/271ov_bitrate misbehaviour with gcc3 + optimizations2017-04-08T10:59:27Zflexoov_bitrate misbehaviour with gcc3 + optimizations```
When ov_bitrate(&vf,-1) (on the whole stream) from libvorbis 1.0 compiled with
gcc3.2 (also happens with gcc 3.1) and default optimizations is called on a
seekable file it returns -2147483648 regardless of the file. (On a nonseekable...```
When ov_bitrate(&vf,-1) (on the whole stream) from libvorbis 1.0 compiled with
gcc3.2 (also happens with gcc 3.1) and default optimizations is called on a
seekable file it returns -2147483648 regardless of the file. (On a nonseekable
file getting the nominal bitrate works fine) When compiled with ``make debug''
(and so optimizations disabled) it doesn't occur.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/Infrastructure/-/issues/269There is no 1.0release option under 'version'2017-04-07T12:17:40ZPeter HarrisThere is no 1.0release option under 'version'```
I just submitted a bug (#268) against oggenc. It should have been against 1.0
final, but the newest version in the 'version' box is 1.0RC3. Please make sure
1.0 final is an option in all the 'version' selection boxes.
Thanks.
``````
I just submitted a bug (#268) against oggenc. It should have been against 1.0
final, but the newest version in the 'version' box is 1.0RC3. Please make sure
1.0 final is an option in all the 'version' selection boxes.
Thanks.
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/267[DOCUMENTATION] man page not specific on extra comments for oggenc2007-06-17T09:04:01ZGitlab Bot[DOCUMENTATION] man page not specific on extra comments for oggenc```
I recently installed the version 1.0 RPMs, and am using oggenc.
The man page has an entry:
-c comment, --comment comment
Add the string comment as an extra comment. This
may be used multiple tim...```
I recently installed the version 1.0 RPMs, and am using oggenc.
The man page has an entry:
-c comment, --comment comment
Add the string comment as an extra comment. This
may be used multiple times, and all instances will
be added to each of the input files specified.
I assumed this works like the other comment options. It doesn't. It requires both a comment name and a comment value, rather than just a value. The error I got was 'Warning: Illegal comment used ("various comments I tried"), ignoring.'
Here's a sample usage of oggenc:
WRONG:
oggenc -q 4.99 -N 01 -t "Why" -a "Annie Lennox" -l "Diva" \
-c "perfect rip w/ Monty's cdparanoia" \
-c "encoded w/ oggenc at -q 4.99" -n \
"%a_-_%l_-01-_%t_4m53s.ogg" track01-ald.wav
CORRECTED:
oggenc -q 4.99 -N 01 -t "Why" -a "Annie Lennox" -l "Diva" \
-c "RIPPER=perfect rip with cdparanoia" \
-c "ENCODER=oggenc at -q 4.99" -n \
"%a_-_%l_-01-_%t_4m53s.ogg" track01-ald.wav
I made this bug report normal severity vs. minor because Google could not find any answer for me except for a single Russian language page that Babelfish could not translate well enough for me.
I can't fix this myself because I don't understand well enough how to build RPMs. I can send a diff for the man page if that would help.
Please cc: me at index@cox.net regarding this.
--Justin Harris
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/266vorbisfile and vorbisenc don't build as shared libraries2017-04-08T10:59:08Zshattyvorbisfile and vorbisenc don't build as shared libraries```
Because the vorbisfile and vorbisenc libraries refer to symbols from the vorbis
lib they error out with undefined symbols during linkage as a shared library.
The attached patch fixes this problem. This patch should be cross platform...```
Because the vorbisfile and vorbisenc libraries refer to symbols from the vorbis
lib they error out with undefined symbols during linkage as a shared library.
The attached patch fixes this problem. This patch should be cross platform. It
may help other platforms to build these libraries as well. (cygwin?)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/Infrastructure/-/issues/265A section for bugs in Ogg* documentation could be nice2017-04-07T16:52:06ZgtgbrA section for bugs in Ogg* documentation could be nice```
This is a follow-up to a heated discussion with Tor-Einar Jarnbjo on vorbis-dev@ - he says his fixes for
the documentation were ignored. Having this new section on Bugzilla would prevent ignoring-by-
accident, while also providing a...```
This is a follow-up to a heated discussion with Tor-Einar Jarnbjo on vorbis-dev@ - he says his fixes for
the documentation were ignored. Having this new section on Bugzilla would prevent ignoring-by-
accident, while also providing a Good Way to report these kinda bugs.
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/vorbis/-/issues/264local_book_besterror in res0.c2017-04-08T10:58:44Zmpxplaylocal_book_besterror in res0.c```
source: res0.c
routine: local_book_besterror
line: 334 (?)
bug: "e++" have to be "e+=dim"
``````
source: res0.c
routine: local_book_besterror
line: 334 (?)
bug: "e++" have to be "e+=dim"
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/Infrastructure/-/issues/263Missing version "1.0" in "Vorbis Tools" new bug page2017-04-07T12:17:40ZpascoggMissing version "1.0" in "Vorbis Tools" new bug page```
To report bugs for "Vorbis Tools" there is a list of versions.
1.0beta*, 1.0rc*, unspecified, but no '1.0' ('final' version).
``````
To report bugs for "Vorbis Tools" there is a list of versions.
1.0beta*, 1.0rc*, unspecified, but no '1.0' ('final' version).
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/261read metadata on startup2019-04-19T11:32:53Zroberead metadata on startup```
it would be great if ices would read the metadata file on startup (not after
the first USR1 is received by the master process) if it's configured to parse
external metadata files at all.
``````
it would be great if ices would read the metadata file on startup (not after
the first USR1 is received by the master process) if it's configured to parse
external metadata files at all.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/libao/-/issues/260if dlopen fails, the next plugin will also fail.2003-08-31T18:10:02Zd95hjortif dlopen fails, the next plugin will also fail.```
The call to dlopen fails to give a handle then the next time _get_plugin is
called it will fail.
This is because dlerror() is never called after the failing dlopen().
Insted the error messag is returned in the test for the first symb...```
The call to dlopen fails to give a handle then the next time _get_plugin is
called it will fail.
This is because dlerror() is never called after the failing dlopen().
Insted the error messag is returned in the test for the first symbol in the next
plugin.
dt->functions->test = dlsym(dt->handle, "ao_plugin_test");
if (dlerror()) { free(dt->functions); free(dt); return NULL; }
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/258device is not compared with NULL in ao_play()2003-08-26T23:16:58Zchristianbieredevice is not compared with NULL in ao_play()```
This bug report is for libao-0.8.3. The "Version" selector of your Bugzilla is
out of date.
ogg123 crashes on Solaris if /dev/audio doesn't exist. The crash happends in
ao_play() line 631 of src/audio_output.c:
if (device->s...```
This bug report is for libao-0.8.3. The "Version" selector of your Bugzilla is
out of date.
ogg123 crashes on Solaris if /dev/audio doesn't exist. The crash happends in
ao_play() line 631 of src/audio_output.c:
if (device->swap_buffer != NULL) {
IMO there's a missing "if (device == NULL) return 0;" although ogg123 should not
call ao_play() with device == NULL.I would also insert NULL checks in ao_close()
just because someone could accidently call it with device == NULL.
BTW, in doc/ao_play.html "ao_play" is wrongly called "ao_open".
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/vorbis/-/issues/257OggEnc gives bad quality with synthetic speech2017-04-08T10:58:44ZtgirmannOggEnc gives bad quality with synthetic speech```
Ogg Vorbis introduces lots of noise into the voice. The problem is easy to hear
at -q 3 and -q 5; at -q 7 it sounds almost okay; here the biggest problem (easy
to hear in direct comparison) is that the heights got a bit louder.
I've...```
Ogg Vorbis introduces lots of noise into the voice. The problem is easy to hear
at -q 3 and -q 5; at -q 7 it sounds almost okay; here the biggest problem (easy
to hear in direct comparison) is that the heights got a bit louder.
I've tried other encoders too; at the same bit rates MP3 (LAME version 3.92 MMX)
suffers from similar problems but it sounds better (when using vbr) while
Musepack sounds almost perfectly.
(side note: when forcing LAME to 128 kbit/s the quality is really bad)
As I selected quality I want oggenc to allocate enough bits to achieve the
desired quality.
See attachment for reverence WAV and Ogg Vorbis examples.
(Yes I'm using OggEnc v1.0 (libvorbis 1.0))
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/256encoder_example (and libvorbis?) leaks memory in managed bitrate mode2017-04-08T10:58:44ZPatrick Bridgesencoder_example (and libvorbis?) leaks memory in managed bitrate mode```
This is in libvorbis 1.0 final.
Change vorbis_encode_init_vbr(...., 0.5) to vorbis_encode_init(..., -1, 128000,
-1) in encoder_example.c (as described in the comments already in that file) and
memory usage grows steadily as data is ...```
This is in libvorbis 1.0 final.
Change vorbis_encode_init_vbr(...., 0.5) to vorbis_encode_init(..., -1, 128000,
-1) in encoder_example.c (as described in the comments already in that file) and
memory usage grows steadily as data is encoded. Memory usage is constant if
_init_vbr() is used instead. Tested on RedHat Linux 7.3, with the gcc version 2.96.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/253OggEnc 1.0 crashes on trivial resampling after encoding (and leaves an unfini...2006-06-12T10:29:53ZtgirmannOggEnc 1.0 crashes on trivial resampling after encoding (and leaves an unfinished ogg file behind)```
Example: oggenc --resample 44100 SomeSong.wav
In my tests SomeSong.wav had 44100 Hz, 16 bits per sample, Stereo.
The crash occurs after encoding is finished and file statistics are printed to
console (but before the buffers are flu...```
Example: oggenc --resample 44100 SomeSong.wav
In my tests SomeSong.wav had 44100 Hz, 16 bits per sample, Stereo.
The crash occurs after encoding is finished and file statistics are printed to
console (but before the buffers are flushed and header is updated). I've
compared 2 files (one encoded with --resample 44100 and one without); the last
0xA92 bytes were missing from the first ogg file and some values in the header
were different (but all other bytes were identical).
The bug is independent from the number of channels (i.e. using --resample or
mono input will cause the bug, too); file size doesn't seem to matter either
(tested files with length of 4 seconds as well as ones with length of 4 minutes)
When setting an invalid bit rate (e.g. -b 32 for CD quality input) the crash
occurs too (immediately now as there's nothing to encode).
IMO this bug is not trivial as it can easily occur when doing batch processing.
Version info (as the appropriate field is missing above):
OggEnc v1.0 (libvorbis 1.0)
(c) 2000-2002 Michael Smith <msmith@l (...) >
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/252Segmentation Fault2007-06-17T08:34:20ZpascoggSegmentation Fault```
oggenc crashes with "Segmentation Fault" with following commands:
--- snip ---
sox /data/audio/aljarreau/audio_01.au -r 44100 -c 2 -w -s -t raw - | oggenc -r
-o test.ogg -
Encoding standard input to
"test.ogg"
at quality ...```
oggenc crashes with "Segmentation Fault" with following commands:
--- snip ---
sox /data/audio/aljarreau/audio_01.au -r 44100 -c 2 -w -s -t raw - | oggenc -r
-o test.ogg -
Encoding standard input to
"test.ogg"
at quality 3.00
Segmentation Fault
test.ogg: 0 bytes
--- snip ---
--- snip ---
sox /data/audio/aljarreau/audio_01.au -r 44100 -c 2 -w -s -t raw - | oggenc -r
--raw-endianness 1 - -o test.ogg
Encoding standard input to
"test.ogg"
at quality 3.00
Segmentation Fault
test.ogg: 0 bytes
[core dump file available, 1.7 MBytes]
--- snip ---
--- snip ---
# Same for MONO
sox /data/audio/aljarreau/audio_01.au -r 44100 -c 1 -w -s -t raw - | oggenc -r
--raw-endianness 1 -C 1 - -o test.ogg
Encoding standard input to
"test.ogg"
at quality 3.00
Segmentation Fault
--- snip ---
--- snip ---
sox /data/audio/aljarreau/audio_01.au audio.wav
oggenc audio.wav
Opening with wav module: WAV file reader
Encoding "audio.wav" to
"audio.ogg"
at quality 3.00
Segmentation Fault
audio.ogg: 0 bytes
--- snip ---
--- snip ---
sox /data/audio/aljarreau/audio_01.au -r 22050 audio.wav
rm audio.ogg
oggenc audio.wav
Opening with wav module: WAV file reader
Encoding "audio.wav" to
"audio.ogg"
at quality 3.00
Segmentation Fault
audio.ogg: 0 bytes
--- snip ---
--- snip ---
sox muppetsong_original.wav -r 22050 -c 2 -w -s -t raw - | oggenc -r
--raw-endianness 1 -R 22050 - -o test.ogg
Encoding standard input to
"test.ogg"
at quality 3.00
Encoding [ 0m20s so far] |Segmentation Fault
!! [REPEATED SAME COMMAND]
sox muppetsong_original.wav -r 22050 -c 2 -w -s -t raw - | oggenc -r
--raw-endianness 1 -R 22050 - -o test.ogg
Encoding standard input to
"test.ogg"
at quality 3.00
Encoding [ 0m21s so far] |Segmentation Fault
test.ogg: 147456 bytes (sounds good so far)
--- snip ---
--- snip ---
oggenc --resample=22050 muppetsong_original.wav
Opening with wav module: WAV file reader
Resampling input from 22254 Hz to 22050 Hz
Encoding "muppetsong_original.wav" to
"muppetsong_original.ogg"
at quality 3.00
[ 31.3%] [ 0m25s remaining] /Segmentation Fault
muppetsong_original.ogg: 98304 [sounds OK]
--- snip ---
BUT ...
--- snip ---
oggenc muppetsong_original.wav
Opening with wav module: WAV file reader
Encoding "muppetsong_original.wav" to
"muppetsong_original.ogg"
at quality 3.00
[ 99.8%] [ 0m00s remaining] \
Done encoding file "muppetsong_original.ogg"
File length: 0m 54.0s
Elapsed time: 0m 25.7s
Rate: 2.1066
Average bitrate: 50.8 kb/s
ogginfo muppetsong_original.ogg
Processing file "muppetsong_original.ogg"...
New logical stream (#1, serial: 000045d9): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20020717 (1.0)
Channels: 1
Rate: 22254
Nominal bitrate: 40.222000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 344425 bytes
Playback length: 0m:54s
Average bitrate: 50.833205 kbps
Logical stream 1 ended
--- snip ---
Used source:
libogg-1.0.tar.gz
libvorbis-1.0.tar.gz
libao-0.8.3.tar.gz
curl-7.9.8.tar.gz
vorbis-tools-1.0.tar.gz
Versions:
OggEnc v1.0 (libvorbis 1.0)
sox: Version 12.17.3
SunOS pmsun20 5.6 Generic_105181-33 sun4m sparc SUNW,SPARCstation-20
ldd `which oggenc`
libvorbisenc.so.2 => /tools/oggvorbis/1.0/lib/libvorbisenc.so.2
libvorbis.so.0 => /tools/oggvorbis/1.0/lib/libvorbis.so.0
libm.so.1 => /lib/libm.so.1
libogg.so.0 => /tools/oggvorbis/1.0/lib/libogg.so.0
libc.so.1 => /lib/libc.so.1
libdl.so.1 => /lib/libdl.so.1
/data/audio/aljarreau/audio_01.au: audio data: 16-bit linear PCM, stereo, 44100
Hz
I tried different things but it still crashes the same way:
- Compiled with GCC 2.8.1
- Compiled with GCC 3.2
- Commented out line 129 in vorbis-tools-1.0/share/iconvert.c
as of BugID 243 and recompiled/reinstalled
[The tries above I actually did it with this version]
Compile log looks good. As there seems to be some problems with iconv
(as of BugID 243) I show you this:
--- snip ---
gcc -DPACKAGE=\"vorbis-tools\" -DVERSION=\"1.0\" -DHAVE_DLFCN_H=1
-DSTDC_HEADERS=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1
-DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_LIMITS_H=1
-DHAVE_LOCALE_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE
_MALLOC_H=1 -DHAVE_STDDEF_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETC
WD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETUID=1
-DHAVE_MUNMAP=1 -DHAVE_PUTENV=1 -DHAVE_SETLOC
ALE=1 -DHAVE_STRCHR=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRTOUL=1
-DHAVE_TSEARCH=1 -DHAVE_ICONV=1 -DICONV_C
ONST=const -DHAVE_LANGINFO_CODESET=1 -DHAVE_LC_MESSAGES=1 -DENABLE_NLS=1
-DHAVE_CURL=1 -DHAVE_PTHREAD=1 -DHAVE_ALLOC
A_H=1 -DHAVE_ALLOCA=1 -DHAVE_ICONV=1 -DICONV_CONST=const -DHAVE_ATEXIT=1
-DHAVE_LANGINFO_CODESET=1 -I. -I. -I../in
clude -O20 -ffast-math -fsigned-char -mv8 -c iconvert.c
iconvert.c: In function `iconvert':
iconvert.c:107: warning: passing arg 2 of `iconv' from incompatible pointer type
iconvert.c:166: warning: passing arg 2 of `iconv' from incompatible pointer type
iconvert.c:178: warning: passing arg 2 of `iconv' from incompatible pointer type
iconvert.c:201: warning: passing arg 2 of `iconv' from incompatible pointer type
iconvert.c:211: warning: passing arg 2 of `iconv' from incompatible pointer type
-- snip ---
REMARKS:
- ogg123 just works fine (file wich I partially could generate, and
downloaded files)
- Version 1.0 missing in Bugzilla form
- sox works as I use it with lame
Let me know if you need more information.
Thanks,
Pascal
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/Infrastructure/-/issues/249impossible to report bugs against Ogg Vorbis 1.02017-04-07T12:17:40ZAdrien Beauimpossible to report bugs against Ogg Vorbis 1.0```
The version fields for libao, Ogg, Vorbis, Vorbis Tools and Vorbis Tools for
Windows don't contain the latest version number (0.8.3, 1.0, 1.0, 1.0 and
1.0), forcing users to use "unspecified" as the version number, e.g. in bugs
#2...```
The version fields for libao, Ogg, Vorbis, Vorbis Tools and Vorbis Tools for
Windows don't contain the latest version number (0.8.3, 1.0, 1.0, 1.0 and
1.0), forcing users to use "unspecified" as the version number, e.g. in bugs
#247 and #248.
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/vorbis/-/issues/246Decoding of 11025 1.0rc3 encoded streams with 1.0 final decoder seems to over...2017-04-08T10:58:44ZgcDecoding of 11025 1.0rc3 encoded streams with 1.0 final decoder seems to over-read```
I'm a developer/packager for Mandrake. We have a bug in "tuxpuck-0.7.91", a
segfault appearing in the "free" call from libvorbis. After a little
investigation, it seems that this stream:
-=-=---=-=---=-=---=-=--
Processing file "noc...```
I'm a developer/packager for Mandrake. We have a bug in "tuxpuck-0.7.91", a
segfault appearing in the "free" call from libvorbis. After a little
investigation, it seems that this stream:
-=-=---=-=---=-=---=-=--
Processing file "nock.ogg"...
New logical stream (#1, serial: 62f352bc): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiphophorus libVorbis I 20011231 (1.0 rc3)
Channels: 1
Rate: 11025
Nominal bitrate not set
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 721 bytes
Playback length: 0m:00s
Average bitrate: 49.798121 kbps
Logical stream 1 ended
-=-=---=-=---=-=---=-=--
which reports a "ov_pcm_total(vf, -1) * channels * 2" of 2554 bytes, when
getting read by ov_read, sends back to the caller 256 bytes, then 256, 256, 1152
and 2048, which makes a total of 3968 bytes - then tuxpuck crashes because
it malloc'ed only 2554 bytes in its buffer.
This bug seems confirmed by using "oggdec" which doesn't segfault but ends
reporting it was at 155.0% of the stream.
We're using the final 1.0 release of Ogg Vorbis (since Sun Jul 21 2002). I've
tried to query this bug database for a duplicate but didn't find one, sorry if
this has already been fixed in the CVS or already reported.
I've put the ogg file here for your convenience though it's in official tuxpuck
package:
http://people.mandrakesoft.com/~gc/files/nock.ogg
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/245libogg's $(includedir) blitzing makes baby Jesus cry2009-04-19T20:17:38ZGitlab Botlibogg's $(includedir) blitzing makes baby Jesus cry```
In include/ogg/Makefile.am, you do:
includedir = $(prefix)/include/ogg
This makes those of us packaging libogg for the LNX-BBC very sad, as we keep
headers off in a side directory that doesn't get installed on the space-limited
Boo...```
In include/ogg/Makefile.am, you do:
includedir = $(prefix)/include/ogg
This makes those of us packaging libogg for the LNX-BBC very sad, as we keep
headers off in a side directory that doesn't get installed on the space-limited
Bootable Business Card. You should find some other way of appending "ogg" to
the $(includedir) variable that makes it so we don't have to hack around you.
Right now when I set --includedir= in the configure script, it is ignored. This
is just bad behavior.
Also, your bug system makes me jump through a ridiculous set of hoops just to
file a fucking bug. Why the hell should *I* set up an account? It's not like
any bugs will be assigned to me or anything. Just store my e-mail address and
move on. It's completely fucking bogus that I should have to go digging through
my mail for confirmation passwords sent by the mailer-daemon address. You're
lucky you get any bugs at all what with the barriers you put up. GARGARGAR!
Also, how come there are no versions in this thing later than rc3? Is anyone
actually using this bug system any more? Have you all moved on to something
sane like debbugs?
Oooh! Bug writing guidelines! Maybe I should follow that link and then submit
this to STRUNK and WHITE! Maybe the dizzying maze of input boxes aren't
STRUCTURE ENOUGH for this thing.
Any serious bug system would have, right on the front page, a big red button
marked "FILE A BUG". It should be easy to file, and then easy to triage. By
using bojira, YOU RUINED CHRISTMAS!
Oh yeah, and I love this doozy:
Bugzilla version 2.14.1
Posting Bug
One moment please...
The name baby jesus is not a valid username. Either you misspelled it, or the
person has not registered for a Bugzilla account.
Please hit the Back button and try again.
The BACK BUTTON, for krissakes. You'd think the folks who DESIGNED A WEB
BROWSER would know how to MAKE A WEB APP that didn't SUCK ARSE in the UI
department! I'll just use my BACK BUTTON to KEY IN MY BUG IN MORSE WHY DON'T I.
```Monty MontgomeryMonty Montgomery