Description of problem: In normal use with the KDE desktop, kaudiocreator won't work because it can't open the cdrom drive exclusively Version-Release number of selected component (if applicable): kdemultimedia-3.5.7-2.fc7 How reproducible: Always Steps to Reproduce: 1.first, launch kaudiocreator, then insert a CD into cdrom-drive _or_ insert a CD into the cd-drive first, then launch kaudiocreator 2. wait for track list to show up in kaudiocreator's CD Tracks tab 3. select some tracks and attempt to rip them Actual results: kaudiocreator fails and throws up an error panel, saying: Unknown error. If you have a cd in the drive try running cdparanoia -vsQ as yourself (not root). Do you see a track list? If not, make sure you have permission to access the CD device. If you are using SCSI emulation (possible if you have an IDE CD writer) then make sure you check that you have read and write permissions on the generic SCSI device, which is probably /dev/sg0, /dev/sg1, etc.. If it still does not work, try typing audiocd:/?device=/dev/sg0 (or similar) to tell kio_audiocd which device your CD-ROM is. Expected results: kaudiocreator rips the selected tracks. Additional info: This didn't occur with kdemultimedia-3.5.7-1.fc6 under FC6 on the same hardware before I updated 3 weeks ago. Running cdparanoia -vsQ, as the error panel suggests, yields: moby(Moonshine) cdparanoia -vsQ ... Checking /dev/cdrom for cdrom... Testing /dev/cdrom for SCSI interface Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying in 1 second. (repeats ad infinitum) yet the ownership/permissions are OK: moby(Moonshine) ls -l /dev/scd0 brw-rw----+ 1 joe disk 11, 0 2007-09-06 11:36 /dev/scd0 lsof points to the problem: [root@moby Moonshine]# lsof | egrep "DEVICE|11,0" COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME kio_audio 30625 joe 14r BLK 11,0 6565 /dev/scd0 kio_audio 30627 joe 13r BLK 11,0 6565 /dev/scd0 kaudiocre 30753 joe 13r BLK 11,0 6565 /dev/scd0 For some reason beyond my understanding, inserting a cd spawns two kio_audiocd processes. Killing the process which has File Descriptor 13 open for reading allows kaudiocreator to gain the exclusive access it requires and kaudiocreator will now happily rip the selected tracks. Killing the process which has File Descriptor _14_ open for reading instead doesn't help, for obvious reasons. Something else interesting happens upon killing the kio_audiocd process which has File Descriptor 13 open for reading -- kded pops up a window (which is invisible below the other open windows) telling me that it has detected a new medium of type Audio CD and asking what I want to do, offering a long menu of appropriate choices. That made me wonder what would happen if I simply inserted an audio CD when kaudiocreator wasn't running. Well, a new Audio CD icon appears on the desktop and lsof shows two kio_audiocd processes start: [root@moby Moonshine]# lsof | egrep "DEVICE|11,0" COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME kio_audio 16319 joe 14r BLK 11,0 6565 /dev/scd0 kio_audio 16321 joe 13r BLK 11,0 6565 /dev/scd0 At this point, if I launch kaudiocreator, either from the commandline, from the kmenu, or by right-clicking the cd icon and choosing "Extract and Encode Audio Tracks", I find myself in the situation described above, with kaudiocreator opening File Descriptor 13 for device scd0 and blocking since it doesn't have it exclusively. However, if I kill the kio_audiocd process with FD 13 open, kded pops up its window asking what I want to do, and when I choose "Extract and Encode Audio Tracks" in that window, kaudiocreator launches and works as expected. Curiously, in this situation it opens File Descriptor _12_ on /dev/scd0: [root@moby Moonshine]# lsof | egrep "DEVICE|11,0" COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME kio_audio 17181 joe 14r BLK 11,0 6565 /dev/scd0 kaudiocre 17387 joe 12r BLK 11,0 6565 /dev/scd0 At this point if I eject the CD after the tracks are ripped and leave kaudiocreator running, inserting another CD again launches two kio_audiocd processes: [root@moby Moonshine]# lsof | egrep "DEVICE|11,0" COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME kaudiocre 17387 joe 12r BLK 11,0 6565 /dev/scd0 kio_audio 17555 joe 14r BLK 11,0 6565 /dev/scd0 kio_audio 18222 joe 14r BLK 11,0 6565 /dev/scd0 kio_audio 18223 joe 13r BLK 11,0 6565 /dev/scd0 and kaudiocreator once again fails. If, and only if, I kill the process that has FD 13 open on /dev/scd0, will kaudiocreator work properly, even though it is using FD _12_ on /dev/scd0. Therefore, it seems to me that the problem is: inserting a CD launches a kio_audiocd process that opens FD 13 on /dev/scd0, my cdrom-drive.
After submitting this report, I was interrupted just after inserting a CD, before I had a chance to kill the kio_audiocd with FD 13 open on /dev/scd0. When I returned, much my surprise, both kio_audiocd's that started upon CD insertion were dead, I was presented with the kded panel asking what I wanted to do, and selecting Extract and Encode Audio Tracks" worked as it should. I the performed the following experiment. I would simultaneously insert a CD and start a loop: [root@pequod ~]# while true; do date +"%H:%M:%S"; lsof | egrep "DEVICE|11,0"; sleep 5; done | tee /tmp/lsof-dev-scd0-p0 to watch when the processes accessing my cdrom-drive were born and died. I did this twice on my desktop (a whitebox I built myself w/ Intel 865PERL mobo and Pioneer DVD-RW DVR-108) and twice on my laptop (Thinkpad T42P w/ MATSHITA DVD-RAM UJ-812). There was some consistency to the results. On both machines, after 15-20 seconds the cdrom-drive would spin up and the two kio_audiocd processes would start, then, after about 3:30 on the desktp and 5:30 on the laptop the process with FD 14 open would die, and finally, 9 minutes and 30 seconds after the start of the experiment on either machine, the process with FD 13 open would die, the kded "What do you want to do window" would pop up, and selecting Extract and Encode Audio Tracks" worked properly. In conclusion I would refine this bug say that inserting a CD triggers a kio_audiocd to open FD 13 on the cdrom-drive, which, for nearly 10 minutes, blocks kded from querying the user about what to do and kaudiocreator from gaining the exclusive read access to the cdrom-drive it needs. I should also point out that there is no such problem inserting DVDs into the drives; the kded "What do you want to do" panel appears as soon as the drive spins up.
*** Bug 188590 has been marked as a duplicate of this bug. ***
Although I did not go as deep in detail as Joe, I can second the behaviour globally (bug 188590). The effect occurs on both my portable (f7, i386) as on my workstation (f7, x86_64).
Has anyone reported this upstream to bugs.kde.org yet? Hint, hint... :)
This is now KDE bz 150151 http://bugs.kde.org/show_bug.cgi?id=150151
However, the fact that the problem only occurred after I switched from FC6 to F7, which were using the same kdemultimedia versions at the time, and am using the same hardware, makes me wonder if this really is an upstream bug. My fingers are crossed; YMMV.
Closing->upstream. Will continue to watch http://bugs.kde.org/135669