Bug 283321 - kaudiocreator is locked out of accessing cd drive
kaudiocreator is locked out of accessing cd drive
Product: Fedora
Classification: Fedora
Component: kdemultimedia (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
: 188590 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-09-07 19:43 EDT by Joe Christy
Modified: 2007-11-30 17:12 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-25 15:14:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 135669 None None None Never
KDE Software Compilation 150151 None None None Never

  None (edit)
Description Joe Christy 2007-09-07 19:43:58 EDT
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):

How reproducible:

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

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

[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.
Comment 1 Joe Christy 2007-09-08 18:54:03 EDT
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.
Comment 2 Rex Dieter 2007-09-17 09:58:17 EDT
*** Bug 188590 has been marked as a duplicate of this bug. ***
Comment 3 Dean Mander 2007-09-23 05:51:28 EDT
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).

Comment 4 Rex Dieter 2007-09-24 08:32:57 EDT
Has anyone reported this upstream to bugs.kde.org yet?  Hint, hint... :)
Comment 5 Joe Christy 2007-09-24 09:55:19 EDT
This is now KDE bz 150151 http://bugs.kde.org/show_bug.cgi?id=150151
Comment 6 Joe Christy 2007-09-24 09:58:02 EDT
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.
Comment 7 Rex Dieter 2007-09-25 15:14:45 EDT
Will continue to watch http://bugs.kde.org/135669

Note You need to log in before you can comment on or make changes to this bug.