Hi, i wrote: > > One big problem is the substantial price of BD-R experiments.
joerg.schill...@fokus.fraunhofer.de wrote: > the OP seems to have turned several BD-Rs into coasters already. The OP reports: > > > I compared each and every file on the disk with its original, > > > but yould not find any problem. This matches Andy Polyakov's diagnosis that the media are ok afterwards. The flawless readbility, the timepoint of failure, and the i/o error reported by K3b, alltogether make me believe that it is the 5 year old bug. Of course, everybody has to decide by himself where to invest test media. My proposal is to fix and test growisofs. --------------------------------------------------------------------- (Joerg and i know each other from many encounters in the past. We do not necessarily agree on technical questions. My apologies for getting off the original topic now.) joerg.schill...@fokus.fraunhofer.de wrote: > Many people reported problems even with writing DVDs using growisofs that > went away after upgrading to cdrtools. "With some fantasy you can see the weirdest things in the mist." (Franquin via Gaston Lagaffe) It is not impossible that a drive refuses on one way of burn preparation while still working with a different one. One might get lucky with the defaults of one burn program and experience failure with those of the other burn program. But normally a drive is on the edge of failure if it behaves that way. The luck may turn quite quickly then. joerg.schill...@fokus.fraunhofer.de wrote: > Note that I already mentioned that growisofs is a layzy written program I would compare its style rather to BASIC than to assembler. :)) But that does not influence its SCSI standards compliance. joerg.schill...@fokus.fraunhofer.de wrote: > has many places where is returns the unly slightly modified result of a SCSI > mode sense operation while running a SCSI mode select operation. As it only > slightly modifies the received data instead of constructing SCSI standard > compliant data, these mode select operations do not always have the desired > effect. How else should one learn the current settings in order _not_ to change those which are non-changeable ? In the source files of growisofs i can spot only one occasion of MODE SELECT. This is in transport.hxx where Andy composes a mode page 05 for DVD-R[W]. I read in SPC-3 6.9.3 that the drive shall throw error if one attempts to change a non-changeable value. But not that the drive is allowed to return values which may cause error if sent back to the drive. So if the code of transport.hxx is wrong, then not because it would send back values which it got from the drive, but because it does not inquire by PC=01b whether its self-constructed values are allowed to be changed. (I don't do this either. It is worth consideration, though.) joerg.schill...@fokus.fraunhofer.de wrote: > This kind of problems is independent from the media type Mode page 05 is only appropriate for CD and DVD-R[W]. (MMC-5 7.5.2, 7.5.3) So this problem is highly dependent on the media type. Have a nice day :) Thomas
