Summary: | media-sound/grip-3.3.1-r2 fails to read SATA drives | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | biohazrd <biohazrd> |
Component: | Current packages | Assignee: | Gentoo Sound Team <sound> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
biohazrd
2009-05-19 04:58:24 UTC
This could be a problem with your optical drive. I have exactly the same problem with my Samsung SH-S223F SATA DVD writer. With cdparanoia I can correctly read whole audio CDs but grip cannot be used with that drive. On the same machine I had a LG GH22NS30 SATA DVD writer which worked perfectly with grip. In case you can rip audio-CDs with cdparanoia, this is no problem with grip but with your drive. So find new firmware for the optical drive or give up on using Grip? Neither choices sound too appealing. I am really fond of Grip, but buying another $130 drive is not ideal. What is the backend of Grip that has issues with drives where CDParanoia does not? What specifically is Grip testing the drive for that fails? (In reply to comment #2) > So find new firmware for the optical drive or give up on using Grip? If there is newer firmware for your drive, it would be worth a try, wouldn't it? > Neither choices sound too appealing. Of course it doesn't. But to be honest what should we people at Gentoo do when the drive is the failing part? Furthermore even if the problem would be with grip, there would be not much we could do as upstream seems to be dead since 2005. > I am really fond of Grip, but buying another $130 drive is not ideal. Of course it is not. I wouldn't spend that much money just for getting a drive which works with grip. But to be honest I spent about $35 for the LG drive especially for the usage with grip. I don't want to recommend you to do the same but I'm afraid that's still the easiest way to get grip working again. > What is the backend of Grip that has issues with drives where CDParanoia does > not? What specifically is Grip testing the drive for that fails? That's beyond my knowledge. Maybe someone else can shed some light to that question. P.S.: There are reports in the grip bug-tracker about problems with SATA-drives as well. So maybe grip is the cause of the problems but I doubt it as my ancient SCSI-drives should fail as well which they don't. http://sourceforge.net/tracker/?func=detail&aid=2735092&group_id=3714&atid=103714 Thank you for your responses. I still tend to think its Grip code that is the problem. The drive is new, no new firmware that I have found and the drive works with everything else. The fact that others have problems with SATA drives and Grip leads me to believe it is a problem with Grip. Most likely whatever back end they have coded to read the drive. I'll just switch to Sound Juicer. I'll install rubyripper to just for giggles. Let's see what our sound herd thinks about this... (In reply to comment #5) > Let's see what our sound herd thinks about this... > I've been using it on my SATA drive for quite a while.. there's no upstream for this package, and I don't have the hardware reporter has.. there's nothing we can do. FYI: I was having the same problem, and I seem to have found a solution. On my system, /dev/cdrom points to /dev/sr0. But it seems that grip really wants a generic scsi device, so I pointed it at /dev/sg1 instead, and that is working. Note that the number of the generic device may be different, as it is on my system. Fortunately, 'ls -l /dev/sg*' showed only one sg device that had group cdrom, which made it obvious. I suspect that this has nothing to do with a hardware fault, and everything to do with how grip talks to the drive. I hope this helps others who hit the same bug. |