Bug 95676 - cd drive locked by kio_audiocd will not eject
Summary: cd drive locked by kio_audiocd will not eject
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: audiocd (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal with 20 votes (vote)
Target Milestone: ---
Assignee: icefox
: 97296 (view as bug list)
Depends on:
Reported: 2004-12-22 17:52 UTC by Tim Booth
Modified: 2006-04-27 11:12 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Tim Booth 2004-12-22 17:52:25 UTC
Version:            (using KDE KDE 3.3.1)
Installed from:    Debian testing/unstable Packages
OS:                Linux

This was mentioned in a comment on another bug:


but the bug itsself (37780) relates to different problems (eg fam) and is now marked as fixed.  This specific issue is still most certainly present in KDE 3.3.1!

Mark Taff said:

I have an ASUS DVD+-R/+-RW as /dev/dvdrecorder linked to /dev/hdd and an Phillips CD-r/rw as /dev/cdrecorder linked to /dev/sd0.  I am using KDE 3.2 Suse rpms on SuSE 9.0.

If I mount either drive with Konqi by clicking the desktop icons, then unmout via the icon right-click menu, and then eject via the icon right-click menu, the eject fails.  I cannot eject from the physical button on the drive.

Even bypassing kdeeject, and going directly to the eject command does not eject it.  I wrote a quick script that calls eject, then loops until it actually ejects.  The time from the first eject command until a successful eject varies from 88 seconds to 491 seconds (over 8 friggin minutes!) with a sample size of five tests.

Mounting, unmounting, and ejecting from a shell (without using Konqi at all) works just fine.

It seems that a kio_audiocd slave is holding up progess.  Manually killing it lets the eject command work immediately.  The cd I was using was _not_ an audio cd, but SuSE 9.0 Pro install disk 1.

Here is my evidence for this conclusion:

mark at Liberty1:/boot/grub> lsof /dev/dvdrecorder
kdeinit 3112 mark  133r   DIR  22,64 4096 59392 /media/dvdrecorder
mark at Liberty1:/boot/grub> lsof /dev/dvdrecorder
kdeinit 4546 mark   12r   BLK  22,64      6409 /dev/hdd
mark at Liberty1:/boot/grub> ps ax | grep 3112
 3112 ?        S      0:04 kdeinit: konqueror --preload
 4559 pts/4    R      0:00 grep 3112
mark at Liberty1:/boot/grub> ps ax | grep 4546
 4546 ?        S      0:00 kdeinit: kio_audiocd audiocd /tmp/ksocket-mark/klauncherTZYQXa.slave-socket /tmp/ksocket-mark/konqueror8sembc.slave-socket
 4562 pts/4    R      0:00 grep 4546
mark at Liberty1:/boot/grub> kill 4546
mark at Liberty1:/boot/grub> lsof /dev/dvdrecorder
mark at Liberty1:/boot/grub>

Please, please, please, kill this bug.



A comment by David Faure says:

After more testing, I can't actually find a case that still doesn't work.
I was wrong about kio_audiocd: although it keeps running, it only cares about the
device, not about the mountpoint, so it doesn't prevent unmounting.
kio_thumbnail doesn't seem to do so either (I can unmount although it's running). 


Well true you can unmount the CD but you can't actually get it out of the drive!!!! 
(apologies for excess exclamation marks)

Please fix this - old ladies laught at me in the street when they hear I can't even eject my CD drive.  (Also apologies if this was fixed in 3.3.2 - I have to wait for the deb before I can test that)

Comment 1 icefox 2004-12-23 21:16:09 UTC
hmmmm  just to make sure it is a audiocd problem you arn't useing kscd or kaudiocreator at anytime right?
Comment 2 Val 2004-12-24 23:37:24 UTC
I also have the same situation where I can actually unmount the cdrom but not
eject it. I have the folowing situation:
I mount a cdrom with a video file and play it from the cdrom. When wanting to
eject via the konqueror sidebar or the devices applet the icon for the device
changes to unmounted but cd is not ejected (popup that eject failed). Killing the kio_audiocd process allows makes eject possible again. I have noticed that everytime I mount the cd the kio_audiocd process is started. I havn't used kscd or kaudiocreator before that situation. Actually kaudiocreator didn't
work when I tried. Using KDE-3.3.1 on Gentoo.
Comment 3 Tim Booth 2004-12-31 12:05:56 UTC
In reply to Benjamin, the machines I am using are running a pretty much clean Debian Sid and I am not doing anything other than creating a device icon on the desktop and clicking it to mount the device.  This appears to be all that is needed to get the kio_audiocd process started.

I'm actually in a position of installing and supporting Debian on machines used by research scientists, and all they want to do is read CD ROMs and burn data to CD with K3B, which is of course just a front-end to cdrecord/cdrdao.  If anyone wants to rip a CD I direct them to use cdparanoia via Grip.  

If you can suggest a workaround to remove the kio_audiocd process completely that would be ideal for me.  I tried deleting the relevant .so file and that seemed to do the trick but I don't know if KDE is going to get upset at having this file missing.  Also, every apt-get upgrade puts the file right back!

Comment 4 icefox 2005-01-02 05:59:59 UTC
If you open KAudioCreator and click on the eject button does it eject right away (The point of this question is that KAudioCreator uses audiocd, but the eject action doesn't)?
Comment 5 icefox 2005-01-02 17:27:12 UTC
Ok, I have been able to reproduce it using "media:/"  :)  And now I can try to solve it.
Comment 6 Tim Booth 2005-01-03 01:28:31 UTC
Thanks, Ben.  I haven't been able to reply to your posts since I am away from work, and hence any KDE installation (I run FluxBox at home).  

If you still need me to try out anything I can do so from Tuesday.

One thing I forgot to mention in the original report - running eject as root actually worked.  I'm not sure why though, as eject -v gave the same diagnostics in both cases.  I don't know if you see the same thing?

Comment 7 Daniel Glöckner 2005-04-25 22:31:51 UTC
This is probably a duplicate of bug 83896 (+ 69517 + 97296). Try the fix that was proposed there. It needs to be slightly modified to apply to current CVS.
Comment 8 Josh Metzler 2005-06-28 15:58:48 UTC
There is a one-line patch proposed in bug 83896, which another user reported working great.  That bug is somehow closed, though the patch is quite obviously still not applied (just looked in trunk):

Please apply.

--- kdemultimedia/kioslave/audiocd/audiocd.cpp~	2004-07-07 10:44:39 +0400
+++ kdemultimedia/kioslave/audiocd/audiocd.cpp	2004-07-07 10:45:11 +0400
@@ -745,6 +745,7 @@ AudioCDProtocol::initRequest(const KURL 
   if (0 != cdda_open(drive))
     error(KIO::ERR_CANNOT_OPEN_FOR_READING, url.path());
+    cdda_close(drive);
     return 0;
Comment 9 Hertz 2005-07-01 07:18:14 UTC
The eject fails even if the device is already unmounted with "eject failed" error message. The only way to eject the cd is to login as root and execute the eject command with root privilegies. I strongy believe this should not work like this.
Distribution: Debian 3.1
KDE: 3.3.2
Comment 10 icefox 2005-07-26 16:32:29 UTC
*** Bug 97296 has been marked as a duplicate of this bug. ***
Comment 11 icefox 2005-07-26 16:55:31 UTC
SVN commit 438910 by bmeyer:

My appologies for all the pain/annoyance this bug has caused. It is also being backported to the 3.4 branch

BUG: 95676

 M  +1 -0      audiocd.cpp  

--- trunk/KDE/kdemultimedia/kioslave/audiocd/audiocd.cpp #438909:438910
@@ -366,6 +366,7 @@
 		kdDebug(7117) << "cdda_open failed" << endl;
 		error(KIO::ERR_CANNOT_OPEN_FOR_READING, url.path());
+		cdda_close(drive); 
 		return 0;