|Summary:||New SG_IO engine causes ripping to hang on IDE DVD-ROM|
|Product:||[Fedora] Fedora||Reporter:||Derek P. Moore <derek.p.moore>|
|Component:||cdparanoia||Assignee:||Peter Jones <pjones>|
|Status:||CLOSED INSUFFICIENT_DATA||QA Contact:|
|Fixed In Version:||alpha9.8-24||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-05-07 00:01:14 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Derek P. Moore 2004-10-04 16:27:46 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041002 Firefox/0.10.1 Description of problem: The new cdparanoia with the SG_IO engine causes ripping to be very slow (0.2x, as reported by Sound Juicer) and hang after about 7 to 10% completion. I'm experiencing these problems on a Toshiba Tecra 8200 laptop with a DVD-ROM drive (TOSHIBA DVD-ROM SD-C2302 using driver ide-cdrom version 4.61). I have yet to give "export CDDA_TRANSPORT=cooked" a try. I simply downgraded to cdparanoia-alpha9.8-21, and the ripping speed and system responsiveness during ripping have returned to normal. Version-Release number of selected component (if applicable): cdparanoia-alpha9.8-23 How reproducible: Always
Comment 1 Peter Jones 2004-10-05 15:59:03 UTC
If you run "cdparanoia 1 /dev/null" instead of sound juicer, what happens? Are there any error or debugging messages shown? Also, does -21 work if you use ide-scsi and sg, instead of /dev/hdc? Did you use this drive to rip with any kernels before 2.6?
Comment 2 Derek P. Moore 2004-10-06 01:14:16 UTC
With -23, I get the following smilies: :-P :-/ ;-( and 8-| And the progress bar fills with V and +. cdparanoia-alpha9.8-23 does report more information during start-up, but they don't seem to be errors. It just has those errors it reports via its normal interface. I'm attaching two text files, each one is the output for that version of cdparanoia. I've only tested these packages on my laptop, which hasn't run 2.4 in a long time (if ever). I haven't tried to use ide-scsi or sg with -21. Should I try for some reason? And how?
Comment 3 Derek P. Moore 2004-10-06 01:16:36 UTC
Created attachment 104816 [details] output of cdparanoia-alpha9.8-21
Comment 4 Derek P. Moore 2004-10-06 01:17:32 UTC
Created attachment 104817 [details] output of cdparanoia-alpha9.8-23
Comment 5 Peter Jones 2004-10-06 20:45:18 UTC
Yep, I can duplicate this now. I think it's a kernel problem, but I'll see about building a -24 today which has a workaround until I can point the blame solidly at us or them ;) Can you test it when it shows up in rawhide?
Comment 6 Derek P. Moore 2004-10-08 01:34:17 UTC
The new build (cdparanoia-alpha9.8-24) is working. It seems to be working a little bit slower than I'm used to. Historically, Sound Juicer reports between 2.0x and 2.2x, but the CD I'm testing with right now seems to top out between 1.5x and 1.8x. Maybe it's the current media, maybe it's the new engine; I'll be able to make a more thorough determination as I rip more (newer) CDs over the next few days. I'm attaching the current output of the new working cdparanoia build, just for completeness. I'll also set this particular bug to resolved. If I determine that cdparanoia is performing more slowly, I'll open a new "cdparanoia performs slower with new engine" bug.
Comment 7 Derek P. Moore 2004-10-08 01:34:59 UTC
Created attachment 104919 [details] output of cdparanoia-alpha9.8-24
Comment 8 Peter Jones 2004-10-08 16:01:26 UTC
I suspect that it is running more slowly -- the workaround for this issue was to change from reading 32 sectors at a time to doing 24 sectors at a time. So for a 74-minute disk that reads perfectly, that's roughly 12000 reads instead of 9000. This seems consistent with your 2.1x -> 1.65x averages. We really should be able to do more than 32 sectors at a time -- on my laptop with a slightly older kernel 55 sectors worked just fine -- but there are some kernel subsystems (usb cd drives especially) that seem to handle this extraordinarily poorly. 32 seemed to always work before. If you set an environmental variable CDDA_IGNORE_BUFSIZE_LIMIT=1 and run cdparanoia, it'll try to do transfers at whatever size the scsi subsystem claims it can do (most likely 55 sectors or so), but my experience with current kernels is that >24 sectors means your reads are garbage. So right now, I think this is a kernel bug, and I want to keep this open to track the status of cdparanoia in this regard. I'd really like to take that workaround _out_, but for now we're stuck reading somewhat suboptimally.
Comment 9 Red Hat Bugzilla 2007-02-05 19:21:09 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 10 Bug Zapper 2008-04-03 15:40:58 UTC
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
Comment 11 Bug Zapper 2008-05-07 00:01:12 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp