> Does > this answer mean that cdrecord fundamentally checks some data that is always > going to give me an error,
Let me re-phrase. Growisofs pulls DISC INFORMATION (that's what the command 0x51 in question does) in a way different from cdrecord, which I believe is/offer as the explanation for why it doesn't get stuck on it. Does it mean that either program does something *fundamentally* wrong? No! Different doesn't mean wrong. > I guess the other question is: what is passing the error on to cdrecord? > The drive? A module that controls USB or SCSI emulation or what? If you're interested in my viewpoint, then I'd say that it appears as if USB transport fails to handle something unit should have never sent (0x22 is a invalid length accoring to MMC, which explicitly says it should be 32+8*n, as already mentioned). Plextor might be able to fix it, USB people might be able to fix it. Will you have hard time convincing either side? Most likely... > Does this mean that growisofs always does check the SCSI status byte? Well, under Linux kernel 2.4 growisofs counts on sr_mod to check the status byte. There is no reason whatsoever to believe that sr_mod doesn't do the job, because if it didn't, growisofs would hardly work at all, not even with IDE units. Under 2.6 growisofs checks the status byte all by itself. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]