From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: When using cdda2wav through xcdroast with a vanilla kernel, cdda2wav sleeps a very long time (over 1 minute. I was to impatient to wait longer). the cdda2wav command line used by xcdroast is cdda2wav -D 2,1,0 -J -g -Q -H -v toc,summary,sectors,titles ps shows that the cdda2wav process is in a sleep state, while nothing else is accessing the cdrom device. Solution: use the previous cdrtools (shipped with RH9) instead of the updated version when using a vanilla kernel. My guess is that the latest locking fix makes the cdrtools unhappy with non-redhat kernels. Version-Release number of selected component (if applicable): cdda2wav-2.0-11.9.1 How reproducible: Always Steps to Reproduce: 1. use vanilla kernel (mine is 2.4.21-rc2-ac1 smp) 2. use xcdroast (with kde) 3. click on duplicate and CD/Image Info Actual Results: nothing. xcdroast waited endlessly for cdda2wav to terminate. Expected Results: xcdroast should have displayed the CD contents after a couple of seconds Additional info: Works OK with cdda2wav-2.0-6
> My guess is that the latest locking fix makes the cdrtools unhappy with > non-redhat kernels. Your guess is wrong... Can you run cdda2wav on the command line, to see more debugging info? maybe with the -V option?
Created attachment 93963 [details] Execution log: cdda2wav 2.0-11.9.1 (RH9-updates) versus 2.0-6 (RH9) OK. This attachement shows the verbose output of cdda2wav-2.0-11.9.1 which takes 45s at the first run, and hangs forever at the second run at the 'read toc size (text)' command. The older version (2.0-6) finishes within 1s. As many runs as I want, always 1s. My kernel: 2.4.21-rc2-ac1 (SMP).
Oops. Small typo. My kernel version is 2.4.22-rc2-ac1 and not 2.4.21-rc2-ac1.
is by any chance autorun or magicdev running?
I'm using kde. autorun is indeed running. magicdev is not.
does it work better, if you kill autorun while you cdda2wav?
Closing due to inactivity. Reopen, if the problem is still existing.