[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: plextor px-708uf: cannot get disk type



> Did I say that cdrecord "squeezes the drive"? No! If I wanted to say
> that, I'd say "Unlike cdrecord, growisofs..." But I said nothing of that
> sort! I said that growisofs asks only for information I consider
> required for intended purpose in a colorful way. I was basically
> answering Thomas' question. Thomas! Did I answer the question "WHY would
> growisofs either not have or not be stopped by this error?" I also tried
> to point out that I don't share the opinion that growisofs success is
> result of bug.

Uh, I am really not trying to egg you guys on, I'm just trying to figure out
why I can't burn DVDs with xcdroast.  Andy, I appreciate your answering this
question, but I am afraid that you have to make it more simple for me.  Does
this answer mean that cdrecord fundamentally checks some data that is always
going to give me an error, and that short of Joerg rewriting cdrecord in
some way (that he thinks would be a mistake) I'm out of luck on this board?

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?  In other
words, is there someone else I can report this error to who might fix it?

> > it just does what the SCSI standard
> > documents: Ask the drive how many bytes it is willing to provide and
> later
> > retrieve them.
> 
> Good for cdrecord.
> 
> > You did not answer if growisofs always checks the SCSI Status byte.
> 
> There was no question "if growisofs always checks the SCSI Status byte"
> [in fact I fail to find any question posed by you in previous post]. But
> I think this unasked question was indirectly answered. Indeed, doesn't
> "if growisofs didn't pay attention to the error code returned by the
> command in question, [it would work at all]" mean "growisofs does pay
> attention"? A.

Sorry, but you lost me again here.  Does this mean that growisofs always
does check the SCSI status byte?  If so, why doesn't it die, too?  And does
this give a clue to the offending module?

Thank you,
Tom




Reply to: