Re: [gentoo-user] k3b burning BD-Disk pretends to fail at 99.99%

[Thomas Schmitt]

Hi,

i wrote:
> > One big problem is the substantial price of BD-R experiments.

Joerg.Schilling@××××××××××××××××.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.Schilling@××××××××××××××××.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.Schilling@××××××××××××××××.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.Schilling@××××××××××××××××.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.Schilling@××××××××××××××××.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