Version: (using KDE KDE 3.3.1) Installed from: Debian testing/unstable Packages OS: Linux This was mentioned in a comment on another bug: http://bugs.kde.org/show_bug.cgi?id=37780#c114 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 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME kdeinit 3112 mark 133r DIR 22,64 4096 59392 /media/dvdrecorder mark at Liberty1:/boot/grub> lsof /dev/dvdrecorder COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME 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. Regards, Mark 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) TIM
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; }