Bug 68381

Summary:	ripping mp3 files with lame hangs
Product:	[Applications] k3b	Reporter:	Helge Deller <deller>
Component:	general	Assignee:	Sebastian Trueg <trueg>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:
Attachments:	sample patch

Description Helge Deller 2003-11-16 16:36:07 UTC

Version:           unknown (using KDE 3.1.93 (CVS >= 20031111), compiled sources)
Compiler:          gcc version 3.3.1 (SuSE Linux)
OS:          Linux (i686) release 2.4.21-99-athlon

when ripping mp3 files with k3b, k3b starts to read the file and lame starts to convert the file in the background, but when k3b tries to finish the ripping after the first song, it hangs and lame reports "[lame] <defunct>" in the process list.

Comment 1 Sebastian Trueg 2004-01-10 14:05:31 UTC

unable to reproduce it...

Comment 2 Helge Deller 2004-01-10 14:23:01 UTC

Hi Sebastian,

I still have the problem. After some debugging it seems, that slotExternalProgramFinished (in kdeextragear-1/k3b/src/audioencoding/external/k3bexternalencoder.cpp) is never called by KProcess (although it should!), and as such the call d->exitWaiter.wait() in finishEncoderInternal() waits endless for the d->exitWaiter.wakeAll() from slotExternalProgramFinished().
I'm running the attached patch (basically I only removed the d->exitWaiter.wait(); call and now it works without problems.

What Distribution are you running - my problems are with SUSE 9, which has a newer glibc and AFAIK where spanned childs needs to be asked in the SIGCHLD signal handler for their return value. But I'm not 100% sure about that.
(Demo-Patch attached)

Comment 3 Helge Deller 2004-01-10 14:23:54 UTC

Created attachment 4078 [details]
sample patch

Comment 4 Sebastian Trueg 2004-01-11 00:30:03 UTC

developing on SuSE 9 here...

Comment 5 Sebastian Trueg 2004-01-11 09:01:03 UTC

reproduced. but I don't understand your patch. What does it do?

Comment 6 Sebastian Trueg 2004-01-11 09:17:08 UTC

anyway, fixed it now with a call to waitpid. Using QWaitCondition was just stupid.