Debian Bug report logs - #517976
significantly more cpu usage on armel than before

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: significantly more cpu usage on armel than before

Date: Tue, 3 Mar 2009 05:12:44 -0500

[Message part 1 (text/plain, inline)]

Package: mpd
Version: 0.14.2-2
Severity: normal

Between version 0.13.2-3lenny1 and 0.14.2-2, mpd has gotten much worse at
mp3[1] sound playback on armel. It seems to be using a *lot* more cpu.

I noticed that when I'm running the stable version, mpd's cpu usage on my
thecus while playing a mp3 is often below 1%. With the unstable version, it
never gets below 20-30%.

This isn't just about CPU load numbers of course. It's about reliably getting
clear playback under load without audio glitches caused by the buffer running
dry, etc. I can reproduce this at will, on two separate arm machines. They are:

turtle: a thecus N2100, with this:
	Bus 002 Device 002: ID 041e:3040 Creative Technology, Ltd SoundBlaster Live! 24-bit External SB0490
box: a qnap ts-109 with the following cheap usb sound dongle:
	Bus 002 Device 005: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter

My first guess is that something has been rewritten and is using floating
point, at which of course, arm sucks[2]. Grepping for "float" in the new source
tree certianly turns up a dozen more than in the old.

pcm_resample_libsamplerate.c looked particularly likely, at a
guess. But configuring --disable-lsr didn't help. Nor did trying
all the samplerate_converter settings, much.

I'm still learning toward it being due to floating point, but
since mpd has become threaded, arm threading innefficies also 
seem plausible.

-- 
see shy jo

[1] I think ogg is also affected, but I've been testing with mp3s only.
[2] armel sucks less, but let's face it: w/o cpu-specific optimised builds,
    it still sucks :-)

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 517976@bugs.debian.org (full text, mbox, reply):

From: Max Kellermann <max@duempel.org>

To: Joey Hess <joeyh@debian.org>, 517976@bugs.debian.org

Subject: Re: Bug#517976: significantly more cpu usage on armel than before

Date: Tue, 3 Mar 2009 11:32:17 +0100

On 2009/03/03 11:12, Joey Hess <joeyh@debian.org> wrote:
> My first guess is that something has been rewritten and is using floating
> point, at which of course, arm sucks[2]. Grepping for "float" in the new source
> tree certianly turns up a dozen more than in the old.
> 
> pcm_resample_libsamplerate.c looked particularly likely, at a
> guess. But configuring --disable-lsr didn't help. Nor did trying
> all the samplerate_converter settings, much.

The libsamplerate code hasn't changed except for cleanups.  This is
where most MPD installations suck most of their CPU.  The fallback
algorithm (pcm_resample_fallback.c) is fast, but its quality is
horrible.

> I'm still learning toward it being due to floating point, but since
> mpd has become threaded, arm threading innefficies also seem
> plausible.

I don't think so.  There are very very few places in MPD where
floating point is actually used, e.g. libsamplerate (libsamplerate
doesn't support fixed-point or integer arithmetics), and that hasn't
changed.

My guess is that you're using software volume.  Since mp3 files are
now decoded in 24 bit (because libmad provides 28 bit samples, and
we're now throwing away 4 bits instead of 12), the software volume
code has to revert to 64 bit integer operations - and this is quite
expensive on 32 bit CPUs.  For i386, mpd.git (0.15~git) contains an
assembly version (simple imul with 64 bit edx:eax result, gcc is too
dumb for generating this obvious solution) - other architectures might
still suffer.

If you're using software volume, try to force MPD to use 16 bit
samples internally (audio_output_format "44100:16:2" in mpd.conf) -
this conversion is performed directly after the decoder, before
anything else is done.  Another idea: set software volume to 100%,
making it a no-op.

Is there any chance you can get me an oprofile report?

Max

Message #15 received at 517976@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Max Kellermann <max@duempel.org>

Cc: 517976@bugs.debian.org

Subject: Re: Bug#517976: significantly more cpu usage on armel than before

Date: Tue, 3 Mar 2009 14:56:24 -0500

[Message part 1 (text/plain, inline)]

Max Kellermann wrote:
> My guess is that you're using software volume.

mixer_type was commented out in my mpdconf, but I tried
explicitly setting it to alsa, and that does seem to help.
Load average while playing mp3s goes down to as low as 11%.

Internet radio, though, shoots the load up to 90%, and it
plays in 1 second burts. Something is still not quite right.
I tried Fastest Sinc Interpolator, which didn't help, and
Linear Interpolator, which keeps the load around 40% for mp3s
but does manage to play streams without gaps.

When I combined mixer_type = alsa with a hand-built mpd w/o
libsamplerate, it got a lot better. Load is 11% for internet
radio and about the same for mp3s, and everything plays w/o problems.

That's comprable to the old version of mpd when used with my current
confguration. (mpdconf attached)

BTW, on this hardware, if I don't uncomment the alsa audio_output
section, sound quality is horrible, full of pops and crackles. The old
version of mpd did not have that problem (much), and uncommenting it
also seems to increase load. I don't know what to make of that, since I
seem to be telling it the same things it would autoprobe (ie, use alsa,
use hw:0,0, the only available device).

> Is there any chance you can get me an oprofile report?

I'd have to mess with kernel modules. Do you still need one?

-- 
see shy jo

[.mpdconf (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 517976@bugs.debian.org (full text, mbox, reply):

From: Max Kellermann <max@duempel.org>

To: Joey Hess <joeyh@debian.org>

Cc: 517976@bugs.debian.org

Subject: Re: Bug#517976: significantly more cpu usage on armel than before

Date: Tue, 3 Mar 2009 21:20:35 +0100

On 2009/03/03 20:56, Joey Hess <joeyh@debian.org> wrote:
> mixer_type was commented out in my mpdconf, but I tried
> explicitly setting it to alsa, and that does seem to help.
> Load average while playing mp3s goes down to as low as 11%.

So part of it was really the software volume code.  Still much more
than before, isn't it?

> Internet radio, though, shoots the load up to 90%, and it
> plays in 1 second burts. Something is still not quite right.
> I tried Fastest Sinc Interpolator, which didn't help, and
> Linear Interpolator, which keeps the load around 40% for mp3s
> but does manage to play streams without gaps.
> 
> When I combined mixer_type = alsa with a hand-built mpd w/o
> libsamplerate, it got a lot better. Load is 11% for internet radio
> and about the same for mp3s, and everything plays w/o problems.

Does your sound chip really require resampling?  With "plughw" instead
of "hw", ALSA would do the resampling - horrible quality, but less CPU
usage, comparable to MPD's fallback algorithm.

I'm wondering what the difference between local mp3 files and internet
radio might be.  Maybe your CPU is running hot in a busy network loop?
Different sampling rate?

Which thread causes high CPU usage?  Get me a backtrace.

Try one more configuration: uncomment the audio_output_format line
(with the proper sample rate - the one suported by your sound chip).

> That's comprable to the old version of mpd when used with my current
> confguration. (mpdconf attached)
> 
> BTW, on this hardware, if I don't uncomment the alsa audio_output
> section, sound quality is horrible, full of pops and crackles. The old
> version of mpd did not have that problem (much), and uncommenting it
> also seems to increase load. I don't know what to make of that, since I
> seem to be telling it the same things it would autoprobe (ie, use alsa,
> use hw:0,0, the only available device).

Without configuration, recent ALSA versions enable dmix.  dmix is a
horrible kludge, and I explicitly disable it on all of my machines.
ALSA can however be quite picky when configuring "hw:0,0", try
"plughw:0,0" and see if it helps.

> > Is there any chance you can get me an oprofile report?
> 
> I'd have to mess with kernel modules. Do you still need one?

It'd be very helpful to see profiling data, but let's experiment with
some settings first, maybe we find it without an oprofile.

Right now, I'm working on reducing MPD's thread synchronization
overhead - this is one thing which has become worse since 0.13.  I'll
let you know when I've got a patch to test.

Max

Message #25 received at 517976@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Max Kellermann <max@duempel.org>

Cc: 517976@bugs.debian.org

Subject: Re: Bug#517976: significantly more cpu usage on armel than before

Date: Tue, 3 Mar 2009 16:38:07 -0500

[Message part 1 (text/plain, inline)]

Max Kellermann wrote:
> On 2009/03/03 20:56, Joey Hess <joeyh@debian.org> wrote:
> > mixer_type was commented out in my mpdconf, but I tried
> > explicitly setting it to alsa, and that does seem to help.
> > Load average while playing mp3s goes down to as low as 11%.
> 
> So part of it was really the software volume code.  Still much more
> than before, isn't it?

Well, sorta.

With the old mpd and the config I sent you, it
runs 1% or less most of the time for mp3s.
Radio though, is unusable, and the busy process is
running libsamplerate.

With old mpd and w/o specifying hw:0.0, it runs 11% for mp3s.
The busy process is, I guess, spending time in dmix?

0x406a24d4 in poll () from /lib/libc.so.6
(gdb) bt
#0  0x406a24d4 in poll () from /lib/libc.so.6
#1  0x4027ce64 in ?? () from /usr/lib/libasound.so.2
 
Audio quality is not always good, some crackling.

In this same configuration, playing radio works great. 
There are two busy processes:

32330 joey      20   0 14180 5640 3580 S 13.5  4.4   0:58.65 mpd                
32331 joey      20   0 14076 5224 3200 S  8.1  4.1   0:18.17 mpd     

The first is as the backtrace above, the second is in a select+read
loop, and I assume is streaming in the audio.

> Does your sound chip really require resampling?  With "plughw" instead
> of "hw", ALSA would do the resampling - horrible quality, but less CPU
> usage, comparable to MPD's fallback algorithm.

With plughw and the current Debian mpd build, I still see cpu usage in
the teens for mp3s. Some internet radio plays ok with load as low as
11%, but another station is pure white noise. So I assume turtle's sound
chip does need resampling for some things?

> I'm wondering what the difference between local mp3 files and internet
> radio might be.  Maybe your CPU is running hot in a busy network loop?
> Different sampling rate?

I think the stations I'm using surely have a lower rate than my mp3s.
They are: http://live.str3am.com:2090/WETS <­- white noise w/o resampling
          http://kqedsc01.streamguys.us:8000/

turtle happens to be my router as well as a mpd box, so it's _always_
got a busy network. But that does not seem to use much cpu.

> Which thread causes high CPU usage?  Get me a backtrace.

With mpd 14.1, with libthreadrate:

For mp3s, only one thread is busy.
This backtrace of that thread while playing a mpd isn't very useful,
beyond telling us what that thread was broadly doing, so let me know if
I need to rebuild libmad w/debugging to get a better one.

0x4055d120 in ??
    () from /usr/lib/libmad.so.0
(gdb) bt
#0  0x4055d120 in ?? () from /usr/lib/libmad.so.0
Cannot access memory at address 0x10a29c6

For internet radio, a different thread needs more cpu than the box
has, and that one is busy in libsamplerate:

0x40148f34 in ??
    () from /usr/lib/libsamplerate.so.0
(gdb) bt
#0  0x40148f34 in ?? () from /usr/lib/libsamplerate.so.0
Cannot access memory at address 0x91fa32

> Try one more configuration: uncomment the audio_output_format line
> (with the proper sample rate - the one suported by your sound chip).

I've tried playing around with that w/o success before. How can
I determine the rate the sound card supports?

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 517976@bugs.debian.org (full text, mbox, reply):

From: Max Kellermann <max@duempel.org>

To: Joey Hess <joeyh@debian.org>

Cc: 517976@bugs.debian.org

Subject: Re: Bug#517976: significantly more cpu usage on armel than before

Date: Tue, 3 Mar 2009 22:56:45 +0100

On 2009/03/03 22:38, Joey Hess <joeyh@debian.org> wrote:
> Max Kellermann wrote:
> > So part of it was really the software volume code.  Still much more
> > than before, isn't it?
> 
> Well, sorta.
> 
> With the old mpd and the config I sent you, it
> runs 1% or less most of the time for mp3s.
> Radio though, is unusable, and the busy process is
> running libsamplerate.

Which means that your sound chip supports the sample rate of your mp3
files, but the radio has an unsupported sample rate.

> With old mpd and w/o specifying hw:0.0, it runs 11% for mp3s.
> The busy process is, I guess, spending time in dmix?

dmix forces everybody to play at 48kHz.  So, yes, that's possible.

> 0x406a24d4 in poll () from /lib/libc.so.6
> (gdb) bt
> #0  0x406a24d4 in poll () from /lib/libc.so.6
> #1  0x4027ce64 in ?? () from /usr/lib/libasound.so.2
>  
> Audio quality is not always good, some crackling.

That's the ALSA thread.  MPD's latency is too high, which is what I'm
working on...

Try the following: edit src/pipe.h and increase CHUNK_SIZE to 16384.
This worked for some other machines which had the same latency
problem.

> In this same configuration, playing radio works great. 
> There are two busy processes:
> 
> 32330 joey      20   0 14180 5640 3580 S 13.5  4.4   0:58.65 mpd                
> 32331 joey      20   0 14076 5224 3200 S  8.1  4.1   0:18.17 mpd     
> 
> The first is as the backtrace above, the second is in a select+read
> loop, and I assume is streaming in the audio.

The second is the decoder thread, which is also doing input from
file/HTTP.

> > Does your sound chip really require resampling?  With "plughw" instead
> > of "hw", ALSA would do the resampling - horrible quality, but less CPU
> > usage, comparable to MPD's fallback algorithm.
> 
> With plughw and the current Debian mpd build, I still see cpu usage in
> the teens for mp3s. Some internet radio plays ok with load as low as
> 11%, but another station is pure white noise. So I assume turtle's sound
> chip does need resampling for some things?

White noise can't come from a wrong sample rate, this problem must be
somewhere else..

> > I'm wondering what the difference between local mp3 files and internet
> > radio might be.  Maybe your CPU is running hot in a busy network loop?
> > Different sampling rate?
> 
> I think the stations I'm using surely have a lower rate than my mp3s.
> They are: http://live.str3am.com:2090/WETS <­- white noise w/o resampling

That's 32 kHz.  That's unusual.

>           http://kqedsc01.streamguys.us:8000/

22 kHz.

> turtle happens to be my router as well as a mpd box, so it's
> _always_ got a busy network. But that does not seem to use much cpu.
> 
> > Which thread causes high CPU usage?  Get me a backtrace.
> 
> With mpd 14.1, with libthreadrate:
> 
> For mp3s, only one thread is busy.
> This backtrace of that thread while playing a mpd isn't very useful,
> beyond telling us what that thread was broadly doing, so let me know if
> I need to rebuild libmad w/debugging to get a better one.

No.  That's the decoder thread again.  It's also doing the
audio_output_format conversion (in case you have configured it).

> For internet radio, a different thread needs more cpu than the box
> has, and that one is busy in libsamplerate:
> 
> 0x40148f34 in ??
>     () from /usr/lib/libsamplerate.so.0
> (gdb) bt
> #0  0x40148f34 in ?? () from /usr/lib/libsamplerate.so.0
> Cannot access memory at address 0x91fa32

On a weak FPU, libsamplerate is too expensive...  but there is no
other way to resample while retaining quality.  ALSA (and ALSA's OSS
emulation) can resample, and of course MPD's fallback resampler can do
it, but its quality sucks.  I'm wondering why MPD 0.13 was faster -
however I guess that libsamplerate wasn't used at all, because without
knowing, you let ALSA do the resampling.

> I've tried playing around with that w/o success before. How can
> I determine the rate the sound card supports?

It's hidden somewhere in /proc/asound, /proc/asound/card0/codec#0 on
my machine.

mpd 0.15~git has better debugging messages, just in case you want to
try it:

 git://git.musicpd.org/master/mpd.git

Max

Message #35 received at 517976@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Max Kellermann <max@duempel.org>

Cc: 517976@bugs.debian.org

Subject: Re: Bug#517976: significantly more cpu usage on armel than before

Date: Tue, 3 Mar 2009 19:10:28 -0500

[Message part 1 (text/plain, inline)]

Max Kellermann wrote:
> On 2009/03/03 22:38, Joey Hess <joeyh@debian.org> wrote:
> > With the old mpd and the config I sent you [...]

> > 0x406a24d4 in poll () from /lib/libc.so.6
> > (gdb) bt
> > #0  0x406a24d4 in poll () from /lib/libc.so.6
> > #1  0x4027ce64 in ?? () from /usr/lib/libasound.so.2
> >  
> > Audio quality is not always good, some crackling.
> 
> That's the ALSA thread.  MPD's latency is too high, which is what I'm
> working on...

Remember the backtrace above is with the old, unthreaded mpd. So it's
probably a red herring if you're thinking about threading.

> Try the following: edit src/pipe.h and increase CHUNK_SIZE to 16384.
> This worked for some other machines which had the same latency
> problem.

I tried this with and without libsamplerate. There did seem
to be a small benefit.

libsamplerate:
	radio: 80% and still unable to keep buffer full
	mp3: 14%
fallback:
	radio: 2%
	mp3: 10%

> On a weak FPU, libsamplerate is too expensive...  but there is no
> other way to resample while retaining quality.  ALSA (and ALSA's OSS
> emulation) can resample, and of course MPD's fallback resampler can do
> it, but its quality sucks.  I'm wondering why MPD 0.13 was faster -
> however I guess that libsamplerate wasn't used at all, because without
> knowing, you let ALSA do the resampling.

I guess so.

I can't hear the quality problems with the fallback resampler
(I can with some of the faster libsamplerate converters), so
personally I'd be happy enough on these machines if I could just
enable it w/o maintaining my own build of mpd.

> It's hidden somewhere in /proc/asound, /proc/asound/card0/codec#0 on
> my machine.

No codec#0 but I found a stream0 that lists a number of interfaces with
rates. Mostly 44100, some 48000, a few 96000. I tried plugging in each
of those numbers to audio_output_format but none of them keep
libsamplerate from chewing up the cpu when playing my radio stream.

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 517976@bugs.debian.org (full text, mbox, reply):

From: Max Kellermann <max@duempel.org>

To: Joey Hess <joeyh@debian.org>

Cc: 517976@bugs.debian.org

Subject: Re: Bug#517976: significantly more cpu usage on armel than before

Date: Wed, 4 Mar 2009 06:51:01 +0100

On 2009/03/04 01:10, Joey Hess <joeyh@debian.org> wrote:
> I tried this with and without libsamplerate. There did seem to be a
> small benefit.

Good, let's see what happens with my new buffer passing code, when
it's ready.

> I can't hear the quality problems with the fallback resampler (I can
> with some of the faster libsamplerate converters), so personally I'd
> be happy enough on these machines if I could just enable it w/o
> maintaining my own build of mpd.

As you wish, I will make a compile-time option for preserving the
fallback integer-only resampler even when libsamplerate is enabled,
which is interesting for platforms with a weak FPU.

> No codec#0 but I found a stream0 that lists a number of interfaces
> with rates. Mostly 44100, some 48000, a few 96000. I tried plugging
> in each of those numbers to audio_output_format but none of them
> keep libsamplerate from chewing up the cpu when playing my radio
> stream.

The ALSA /proc stuff is confusing, and there is no unified format..
you can see the current hardware sample rate in
/proc/asound/card*/pcm*p/sub*/hw_params while you're playing
something.  MPD 0.15~git also logs this stuff in --verbose mode.

Max

Message #45 received at 517976@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Max Kellermann <max@duempel.org>

Cc: 517976@bugs.debian.org

Subject: Re: Bug#517976: significantly more cpu usage on armel than before

Date: Wed, 4 Mar 2009 12:22:32 -0500

[Message part 1 (text/plain, inline)]

Max Kellermann wrote:
> As you wish, I will make a compile-time option for preserving the
> fallback integer-only resampler even when libsamplerate is enabled,
> which is interesting for platforms with a weak FPU.

So there will be a way to enable it at runtime in mpdconf?
 
> > No codec#0 but I found a stream0 that lists a number of interfaces
> > with rates. Mostly 44100, some 48000, a few 96000. I tried plugging
> > in each of those numbers to audio_output_format but none of them
> > keep libsamplerate from chewing up the cpu when playing my radio
> > stream.
> 
> The ALSA /proc stuff is confusing, and there is no unified format..
> you can see the current hardware sample rate in
> /proc/asound/card*/pcm*p/sub*/hw_params while you're playing
> something.  MPD 0.15~git also logs this stuff in --verbose mode.

access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 45
buffer_size: 22050

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Message #50 received at 517976@bugs.debian.org (full text, mbox, reply):

From: John Eikenberry <jae@zhar.net>

To: 517976@bugs.debian.org

Subject: Re: Bug#517976: significantly more cpu usage on armel than before

Date: Thu, 12 Mar 2009 20:35:02 -0400

[Message part 1 (text/plain, inline)]

> dmix forces everybody to play at 48kHz.  So, yes, that's possible.

You can control this in your .asoundrc using the rate parameter. I have it
set to 44100 in mine so that it doesn't have to re-sample my music. I
included a simple example below.

I also set the period_size size in the example. I found that setting it to
2048 totally eliminated the pops and crackles when listening to online
radio.



pcm.card0 {
    type hw
    card 0
}

ctl.card0 {
    type hw
    card 0
}

pcm.mix {
    type dmix
    ipc_key 1234
    slave { 
        pcm "card0"
        period_size 2048
        rate 44100
    }
}

pcm.!default mix



-- 

John Eikenberry
[jae@zhar.net - http://zhar.net]
[PGP public key @ http://zhar.net/jae_at_zhar_net.gpg]
______________________________________________________________
"Perfection is attained, not when no more can be added, but when no more 
 can be removed." -- Antoine de Saint-Exupery

[signature.asc (application/pgp-signature, inline)]

Message #55 received at 517976@bugs.debian.org (full text, mbox, reply):

From: Max Kellermann <max@duempel.org>

To: John Eikenberry <jae@zhar.net>, 517976@bugs.debian.org

Subject: Re: Bug#517976: significantly more cpu usage on armel than before

Date: Fri, 13 Mar 2009 07:11:55 +0100

On 2009/03/13 01:35, John Eikenberry <jae@zhar.net> wrote:
> I also set the period_size size in the example. I found that setting
> it to 2048 totally eliminated the pops and crackles when listening
> to online radio.

MPD 0.15~git has an important patch in that regard:

 http://git.musicpd.org/cgit/master/mpd.git/commit/?id=554a34fb958cfa15c00a81671a72079cae00ca5f

If 0.15 comes too late, we will eventually backport that (and other
patches) to 0.14.3.

Max

Message #60 received at 517976@bugs.debian.org (full text, mbox, reply):

From: Max Kellermann <max@duempel.org>

To: Joey Hess <joeyh@debian.org>, 517976@bugs.debian.org

Subject: Re: Bug#517976: significantly more cpu usage on armel than before

Date: Sat, 14 Mar 2009 15:27:33 +0100

On 2009/03/04 18:22, Joey Hess <joeyh@debian.org> wrote:
> Max Kellermann wrote:
> > As you wish, I will make a compile-time option for preserving the
> > fallback integer-only resampler even when libsamplerate is enabled,
> > which is interesting for platforms with a weak FPU.
> 
> So there will be a way to enable it at runtime in mpdconf?

I have committed the patch:

 http://git.musicpd.org/cgit/master/mpd.git/commit/?id=e12140cfce88985f9fcecb93214a94a0b9c33e7f

Message #65 received at 517976-done@bugs.debian.org (full text, mbox, reply):

From: Florian Schlichting <fsfs@debian.org>

To: 517976-done@bugs.debian.org, Joey Hess <joeyh@debian.org>

Cc: control@bugs.debian.org

Subject: Re: Bug#517976: significantly more cpu usage on armel than before

Date: Tue, 9 Apr 2013 11:05:16 +0200

Fixed: 0.15-1
thanks

from skimming the bug log, I believe the issue was fixed with the two
commits mentioned in messages #55 and #60, long ago in 2009

Florian

Send a report that this bug log contains spam.