Bug 95676

hmmmm  just to make sure it is a audiocd problem you arn't useing kscd or kaudiocreator at anytime right?

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.

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!

Thanks,
TIM

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)?

Ok, I have been able to reproduce it using "media:/"  :)  And now I can try to solve it.

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?

TIM

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.

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;
   }

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

*** Bug 97296 has been marked as a duplicate of this bug. ***

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;
 	}