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