Comment 16 for bug 1757030

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

> Is there a way to place a DVD burner into simulation mode as with CD
> recording so as to test the commands without wasting the disc?

Not with DVD+R and DVD+R DL, i fear.
Only DVD-R and unformatted DVD-RW can simulate.

> nodao.log

Now that's a short one.
It can hardly be that growisofs issues a wrong command here. At most
there can be something missing.

It tries to learn some info about the medium, is convinced that it is
a blank DVD+R DL, and begins to write.
The first WRITE(10) command needs 72 seconds to fail.

  WRITE(10)
  2a 00 00 00 00 00 00 00 10 00
  ...
  +++ key=5 asc=21h ascq=04h ( 72020 ms)
  :-[ WRITE@LBA=0h failed with SK=5h/ASC=21h/ACQ=04h]: Invalid argument

Neither SPC-3 nor MMC-5 specifies this code. Its neighbors are
  5 21 00 LOGICAL BLOCK ADDRESS OUT OF RANGE
  5 21 01 INVALID ELEMENT ADDRESS
  5 21 02 INVALID ADDRESS FOR WRITE
  5 21 03 INVALID WRITE CROSSING LAYER JUMP

I.e. the drive does not like the write target address. But this might
be just a consequence of the drive or bus reset.

> dao.log

This seems to have succeeded.

But the image was much smaller than in your original run.

  /dev/dvdrw: splitting layers at 1167120 blocks

  (NOT IN COMMAND LIST)
  bf 00 00 00 00 00 00 20 00 0c 00 00
  To drive: 12b
  00 0a 00 00 00 00 00 00 00 11 cf 10
   91120 ms

Command code 0xBF is "SEND DISC STRUCTURE". I should add it to the list
in the patch.
Does this really last 92 seconds ?

  WRITE(10)
  2a 00 00 23 9e 00 00 00 10 00
       8 ms
  /dev/dvdrw: flushing cache

  SYNCHRONIZE CACHE
  35 02 00 00 00 00 00 00 00 00
       0 ms

The last WRITE(10) command wrote up to block 0x239e00 + 15 = 2334223.
So the total size is 2334224, which divided by 2 is 1167112.
So growisofs rounded up the layer break position by 8 blocks.

In the original run, the block count was 8231090176 / 2048 = 4019087.
Divided by 2: 2009543.5 . "splitting layers at 2009552 blocks" means
that growisofs rounded up by 8.5 blocks.

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

This still gives me no idea what growisofs might do wrong.
The nodao.log is quite what i would expect from xorrecord -tao, too.

If you find reason to burn a DVD+R DL with xorrecord, then you could use
option -V and post the log here.
You may then omit the legthy sequences of WRITE(10) and READ BUFFER CAPACITY.
It suffices to show the first few WRITE(10) and the last few WRITE(10)
together with the other commands before and after the WRITE(10) flood.

Have a nice day :)

Thomas