Bug 150151

Version:           KAudioCreator 1.13 (Using KDE 3.5.7-21.fc7 Fedora) (using KDE KDE 3.5.7)
Installed from:    Fedora RPMs
Compiler:          I use gcc-4.1.2-12. I don't know what version the packager used. 
OS:                Linux

cf Fedora bz 283321, https://bugzilla.redhat.com/show_bug.cgi?id=283321, from which I quote (cutting and pasting mangled the word wrap, alas):

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.


Comment #1 From Joe Christy (joe@eshu.net) 	on 2007-09-08 18:54 EST 	[reply] 	 

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.