Bug 150151 - kaudiocreator is locked out of accessing cd drive
Summary: kaudiocreator is locked out of accessing cd drive
Status: RESOLVED DUPLICATE of bug 135669
Alias: None
Product: kaudiocreator
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Gerd Fleischer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-24 15:52 UTC by Joe Christy
Modified: 2007-09-25 20:51 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Christy 2007-09-24 15:52:30 UTC
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.
Comment 1 Richard Lärkäng 2007-09-24 21:51:33 UTC
If you don't have kaudiocreator running, but KDE still running and insert a cd does
cdparanoia -vsQ work? (Wait for the kio_audiocd processes to start)
Comment 2 Joe Christy 2007-09-24 23:34:57 UTC
If I can execute cdparanoia -vsQ in the split second after hald, I suppose, notices the cd insertion, but before kde pops up the "what do you want to do about this cd" panel, cdparanoia will work.

If I'm really fast and execute cdparanoia before the cd even spins up, or slower and excute cdparanoia once that panel has appeared, cdparanoia gives the accustomed:

moby(~) cdparanoia -vsQ
cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <monty@xiph.org> and Xiphophorus

Report bugs to paranoia@xiph.org
http://www.xiph.org/paranoia/

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.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying in 1 second.
...
ad inifintum.

Even if I wait for thge panel and either hit "cancel" or select "Do nothing", then clock "OK", cdparanoia will fail in the same way.
Comment 3 Richard Lärkäng 2007-09-25 20:51:01 UTC
Ok, so the problem isn't in kaudiocreator at least. Something seems to go wrong with either the audiocd ioslave, the media ioslave (which I think is responsible for the popup), or something at a lower level (like hal).

I found now that this report seems to be a duplicate of bug #135669, so closing as a duplicate of that one.

*** This bug has been marked as a duplicate of 135669 ***