Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

Andy Polyakov wrote:
> The unit in question [Gregoire's] obviously crashes (power cycle is
> required to bring it back, i.e. reboot of unit) if write request crosses
> layer break position.
> It sounds as if their [Rob's and CJ's]
> units can't handle arbitrary layer break positions and has to be reminded

i wrote:
> 2086912 - 2086889 == 23
> The failing write command [of cdrecord with Gregoire's drive]
> is 31 blocks long and thus touches both layers.

Joerg Schilling wrote:
> It may be that this has been forgotten in cdrecord's code (it was planned ;-)
> if it works with other drives, then other drives do not follow the worst 
> possible firmware documented by the MMC standard.


So the current consolidated theory would be
about like this:

---------

Problem number 1:
Rob and CJ have drives which do not like any
other layer break address than the one which
is their default.
Thus growisofs and cdrecord fail if their
automatically computed layer breaks get set.
The remedy is to enforce the drive's default
layer break address and override the programs'
computations.
(This would mean that cdrskin has no problem
with those drives. I would appreciate
confirmation.)

---------

Problem number 2:
Gregoire's drive does not like if cdrecord's
31-block aligned write command touches both
layers together by a single write command.
It seems not to have a general layer break
setting problem, because growisofs with its
automatic layer break and its 16-block aligned
write commands only fails much after the layer
break.
(One could verify this therory by aligning
the manual layer break to a multiple of 496.)

---------

Problem number 3:
Gregoire's drive has a yet obsure problem with
drive-media compatibility which shows up
with growisofs and cdrskin but not with Nero.
I am still clueless what preparations Nero could
do to increase that compatibility.

If 496-alignment allows cdrecord to cross the
layer break, then it would be interesting to
see whether it has write errors, too.

---------

Let me add another growisofs problem report which
i got from a scdbackup user:

With DVD+R DL, growisofs seems to read the size of
the ISO image and to announce that size for the
write run. If scdbackup adds its checksum list
and (superstitious) padding, then the write run
aborts less than 32 blocks after the end of
the ISO image.
mkisofs reports:
  3916389 extents written (7649 MB)
growisofs -Z /dev/...=/dev/fd0 reports:
  :-[ WRITE@LBA=3bc280h failed with SK=5h/END OF USER AREA ENCOUNTERED ON
That is 27 sectors after the end of the image
(in the the data tail added by scdbackup).

The same growisofs command works well with DVD+R
and sequential DVD-RW. So the rigid size curb
seems to be a speciality with the handling of
DVD+R DL in growisofs.
In a further attempt, cdrskin wrote the whole
stream to DVD+R DL with no error messages.
(The readability of the media was mediocre,
though. I/o errors with several payload files.
So the user went back to single layer media.
Elsewise i would now advise him to set a
maximum manual layerbreak by 
 -use-the-force-luke=break:size
)

-------------


Have a nice day :)

Thomas