Lite-On DS8A1H Slimline fails to record dual layer DVD+R

[Ryan C. Underwood]

I tried Verbatim 8x and 2.4x DVD+R DL. The failure is always exactly the same.

$ growisofs -dvd-compat -Z /dev/dvdrw=2017.iso
Executing 'builtin_dd if=2017.iso of=/dev/dvdrw obs=32k seek=0'
/dev/dvdrw: splitting layers at 2009552 blocks
/dev/dvdrw: "Current Write Speed" is 1.6x1352KBps.
    9175040/8231090176 ( 0.1%) @2.0x, remaining 74:40 RBU 100.0% UBU 7.4%
   21135360/8231090176 ( 0.3%) @2.6x, remaining 58:16 RBU 100.0% UBU 98.8%
   33095680/8231090176 ( 0.4%) @2.6x, remaining 49:32 RBU 100.0% UBU 98.6%
   45056000/8231090176 ( 0.5%) @2.6x, remaining 45:25 RBU 100.0% UBU 98.8%
   57016320/8231090176 ( 0.7%) @2.6x, remaining 45:23 RBU 100.0% UBU 98.8%
   69009408/8231090176 ( 0.8%) @2.6x, remaining 43:22 RBU 100.0% UBU 98.8%
   80969728/8231090176 ( 1.0%) @2.6x, remaining 41:56 RBU 100.0% UBU 98.6%
   92930048/8231090176 ( 1.1%) @2.6x, remaining 42:19 RBU 100.0% UBU 98.6%
[..]
 4077289472/8231090176 (49.5%) @4.1x, remaining 15:15 RBU 90.0% UBU 88.4%
 4096065536/8231090176 (49.8%) @4.1x, remaining 15:11 RBU 43.0% UBU 97.9%
 4114808832/8231090176 (50.0%) @4.1x, remaining 15:06 RBU 28.0% UBU 97.9%
 4115562496/8231090176 (50.0%) @0.2x, remaining 15:08 RBU 69.4% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:12 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:15 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:18 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:22 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:25 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:28 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:32 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:35 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:38 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:42 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:45 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:48 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:52 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:55 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 15:58 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 16:02 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 16:05 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 16:08 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 16:12 RBU 100.0% UBU 100.0%
 4115562496/8231090176 (50.0%) @0.0x, remaining 16:15 RBU 100.0% UBU 100.0%
:-[ WRITE@LBA=1ea9d0h failed with SK=5h/ASC=21h/ACQ=04h]: Invalid argument
:-( write failed: Invalid argument
$ dmesg
[..]
[5033003.021339] capability: warning: `growisofs' uses 32-bit capabilities (legacy support in use)
[5033841.644130] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[5033841.644149] ata1.00: cmd a0/01:00:00:00:80/00:00:00:00:00/a0 tag 0 dma 32768 out
                          Write(10) 2a 00 00 1e d8 40 00 00 10 00res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[5033841.644155] ata1.00: status: { DRDY }
[5033846.688236] ata1: link is slow to respond, please be patient (ready=0)
[5033851.684070] ata1: device not ready (errno=-16), forcing hardreset
[5033851.684086] ata1: soft resetting link
[5033851.888486] ata1.00: configured for MWDMA2
[5033851.889482] ata1: EH complete

xorriso is fine:
$ xorrecord dev='/dev/sr0' -v -dao -pad 2017.iso
xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev '/dev/sr0'
Media current: DVD+R/DL
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 8152m free
Beginning to write data track.
[..]
Writing to '/dev/sr0' completed successfully.

xorriso : NOTE : Re-assessing -outdev '/dev/sr0'
xorriso : NOTE : Disc status unsuitable for writing
Drive current: -outdev '/dev/sr0'
Media current: DVD+R/DL
Media status : is written , is closed
Media summary: 1 session, 4019104 data blocks, 7850m data, 0 free

Disc status afterwards:
$ dvd+rw-mediainfo /dev/dvdrw
INQUIRY: [Slimtype][DVD A DS8A1H ][WH66]
GET [CURRENT] CONFIGURATION:
 Mounted Media: 2Bh, DVD+R Double Layer
 Media ID: MKM/001
 Current Write Speed: 4.0x1385=5540KB/s
 Write Speed #0: 4.0x1385=5540KB/s
 Write Speed #1: 2.4x1385=3324KB/s
GET [CURRENT] PERFORMANCE:
 Write Performance: 1.6x1385=2216KB/s@0 -> 5.8x1385=8036KB/s@4019103
 Speed Descriptor#0: 00/4019103 R@6.0x1385=8310KB/s W@4.0x1385=5540KB/s
 Speed Descriptor#1: 00/4019103 R@6.0x1385=8310KB/s W@2.4x1385=3324KB/s
READ DVD STRUCTURE[#0h]:
 Media Book Type: 00h, DVD-ROM book [revision 0]
 Legacy lead-out at: 2086912*2KB=4273995776
DVD+R DOUBLE LAYER BOUNDARY INFORMATION:
 L0 Data Zone Capacity: 2086912*2KB, can no longer be set
READ DISC INFORMATION:
 Disc status: complete
 Number of Sessions: 1
 State of Last Session: complete
 Number of Tracks: 1
READ TRACK INFORMATION[#1]:
 Track State: invisible
 Track Start Address: 0*2KB
 Free Blocks: 0*2KB
 Track Size: 4019104*2KB
 ROM Compatibility LBA: 262144
FABRICATED TOC:
 Track#1 : 14@0
 Track#AA : 14@4019104
 Multi-session Info: #1@0
READ CAPACITY: 4019104*2048=8231124992

It looks like growisofs has an alignment bug at the layer change. The SCSI error code corresponds to:
21/04 DZ UNALIGNED WRITE COMMAND
http://www.t10.org/lists/asc-num.htm#ASC_21

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: dvd+rw-tools 7.1-11.1
ProcVersionSignature: Ubuntu 4.13.0-25.29-generic 4.13.13
Uname: Linux 4.13.0-25-generic x86_64
NonfreeKernelModules: openafs
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
CurrentDesktop: LXDE
Date: Mon Mar 19 19:15:02 2018
SourcePackage: dvd+rw-tools
UpgradeStatus: Upgraded to artful on 2018-01-06 (72 days ago)

[Ryan C. Underwood (nemesis-icequake)]

I also tried Pioneer BDR-205 Blu-ray recorder, firmware 1.12. growisofs can record any blank DL DVD with no problem. xorriso can record DL DVD on either drive.

So, the problem seems isolated to growisofs and some alignment peculiarity with the firmware of this DS8A1H drive.

[Thomas Schmitt (scdbackup)]

Hi,

the problem looks like it is triggered by growisofs' habit to explicitely
set the layer break position. See its message

  /dev/dvdrw: splitting layers at 2009552 blocks

and its error message

 4115562496/8231090176 (50.0%) @0.0x, remaining 16:15 RBU 100.0% UBU 100.0%
 :-[ WRITE@LBA=1ea9d0h failed with SK=5h/ASC=21h/ACQ=04h]: Invalid argument

The numbers match: 4115562496 / 2048 = 2009552 = 0x1ea9d0

Somewhat riddling is the message from dmesg

   Write(10) 2a 00 00 1e d8 40 00 00 10 00

Some entity tried to write block 0x1ed840 = 2021440 = 2009552 + 11888.
The drive did not like this. (And the culprit should be ashamed.)

> xorriso is fine:

Years ago i decided in libburn against that growisofs gesture. DVD+R DL
are unreliable enough. Complicating their operation by smart commands
seemed unwise.
But on the other hand there were reports that drives worked with growisofs
and DVD+R DL whereas libburn (in that case underneath Xfburn) failed.

In growisofs_mmc.cpp one can see the occasion where sending the
layer break is decided:

            if (profile==0x2B && next_track==1 && dvd_compat && leadout)
                plus_r_dl_split (cmd,leadout);

Influencable from growisofs options is "dvd_compat".
It gets set to non-zero if one fo these options is used:
  -dvd-compat
  -use-the-force-luke=dao
  -dvd-video

So maybe you get a better result when omitting -dvd-compat.
(This might yield an appendable medium which some entertainment DVD player
 might hate. But computer drives should be ok with it.)

> xorrecord dev='/dev/sr0' -v -dao -pad 2017.iso

Padding is needed only to prevent the Linux TAO CD read-ahead bug.
This special misperception of the readable size cannot happen with DVD media.

So if you ever need those last 300 KiB of a non-CD medium or a CD written
by write type SAO, then replace option "-pad" by "-nopad".

Have a nice day :)

Thomas

[Ryan C. Underwood (nemesis-icequake)]

This is terrible. How can growisofs mess this up so badly? I didn't even
eject the disc and immediately can burn the image with xorrecord with no
problems.

$ growisofs -Z /dev/dvdrw=dvd.iso
Executing 'builtin_dd if=dvd.iso of=/dev/dvdrw obs=32k seek=0'
/dev/dvdrw: "Current Write Speed" is 1.6x1352KBps.
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
          0/8320804864 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
:-[ WRITE@LBA=0h failed with SK=5h/ASC=21h/ACQ=04h]: Invalid argument
:-( write failed: Invalid argument

[5509731.308124] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[5509731.308143] ata1.00: cmd a0/01:00:00:00:80/00:00:00:00:00/a0 tag 0 dma 32768 out
                          Write(10) 2a 00 00 00 00 00 00 00 10 00res 40/00:02:00:18:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[5509731.308149] ata1.00: status: { DRDY }
[5509736.352258] ata1: link is slow to respond, please be patient (ready=0)
[5509741.332040] ata1: device not ready (errno=-16), forcing hardreset
[5509741.332052] ata1: soft resetting link
[5509741.536602] ata1.00: configured for MWDMA2
[5509741.537635] ata1: EH complete

--
Ryan C. Underwood, <email address hidden>

[Thomas Schmitt (scdbackup)]

Hi,

this time the layer break position was not set by growisofs.
Now i wonder what is the difference between the commands sent by growisofs
and libburn underneath xorriso.

Looking at the source code of growisofs it seems that no command RESERVE
TRACK is sent for DVD+R DL. libburn sends it if it decided for DAO/SAO-like
writing for which it announces the amount of data in advance.

You could risk a medium and run xorrecord with explicit option -tao
in order to see whether it fails too:

  xorrecord dev=/dev/sr0 -v -tao -pad 2017.iso

(If no -tao or -dao is given, i expect libburn to decide for -dao.)

> :-[ WRITE@LBA=0h failed with SK=5h/ASC=21h/ACQ=04h]: Invalid argument

It is not normal that a blank medium cannot take a first WRITE command
to block 0 and carrying 16 blocks. The error code stems from the drive.
But i cannot imagine what growisofs could have done wrong to get this
reply to its command.

> [5509731.308149] ata1.00: status: { DRDY }
> [5509736.352258] ata1: link is slow to respond, please be patient (ready=0)
> [5509741.332040] ata1: device not ready (errno=-16), forcing hardreset

Some quite short timeout period is to see here. After only 5 seconds the
first complaint appears. 5 seconds later, the device gets reset.

It is not clear to me whether the error was perceived by growisofs before
or after that reset.

If no deterministic explanation can be found, then you have to expect that
xorrecord could fail too with that drive at some random occasion.

Have a nice day :)

Thomas

[Ryan C. Underwood (nemesis-icequake)]

On Wed, Mar 21, 2018 at 04:42:25PM -0000, Thomas Schmitt wrote:
>
> Looking at the source code of growisofs it seems that no command RESERVE
> TRACK is sent for DVD+R DL. libburn sends it if it decided for DAO/SAO-like
> writing for which it announces the amount of data in advance.
>
> You could risk a medium and run xorrecord with explicit option -tao
> in order to see whether it fails too:
>
> xorrecord dev=/dev/sr0 -v -tao -pad 2017.iso
>
> (If no -tao or -dao is given, i expect libburn to decide for -dao.)

With -tao option, xorrecord has no trouble at all.

> > :-[ WRITE@LBA=0h failed with SK=5h/ASC=21h/ACQ=04h]: Invalid argument
>
> It is not normal that a blank medium cannot take a first WRITE command
> to block 0 and carrying 16 blocks. The error code stems from the drive.
> But i cannot imagine what growisofs could have done wrong to get this
> reply to its command.

Is there an easy way to dump the raw commands before the one that
failed? Maybe growisofs has put the drive into a weird state so that
this subsequent normal-looking command fails.

> > [5509731.308149] ata1.00: status: { DRDY }
> > [5509736.352258] ata1: link is slow to respond, please be patient (ready=0)
> > [5509741.332040] ata1: device not ready (errno=-16), forcing hardreset
>
> Some quite short timeout period is to see here. After only 5 seconds the
> first complaint appears. 5 seconds later, the device gets reset.
>
> It is not clear to me whether the error was perceived by growisofs before
> or after that reset.

The reset preceded the userspace error.

> If no deterministic explanation can be found, then you have to expect that
> xorrecord could fail too with that drive at some random occasion.

I suppose, but I have zero problems with xorrecord with any drive or
media so far, so I feel that this is a bug in growisofs with this
specific drive.

--
Ryan C. Underwood, <email address hidden>

[Thomas Schmitt (scdbackup)]

Hi,

> With -tao option, xorrecord has no trouble at all.

I am out of ideas, for now.

> Is there an easy way to dump the raw commands before the one that failed?

I am not aware whether the Linux kernel has a logging facility for
ioctl(SG_IO). That's the system call by which we perform the SCSI command
transactions.

xorrecord has option -V, which produces a log of the SCSI transactions.
Try:

  xorrecord -V dev=/dev/sr0 -inq 2>&1 | less

and see how it talks to the drive via SG_IO.
E.g.:

  INQUIRY
  12 00 00 00 24 00
  From drive: 36b
  05 80 05 32 5b 00 00 00 48 4c 2d 44 54 2d 53 54 42 44 44 56
  44 52 57 20 47 47 43 2d 48 32 30 4c 31 2e 30 33
      9390 us [ 45683 ]

Command INQUIRY was sent. It consisted of 6 bytes "12 00 00 00 24 00".
The drive replied by 36 bytes. As cleartext one can read "HL-DT-ST",
"BDDVDRW GGC-H20L", "1.03".
The transaction lasted 9390 microseconds. Time elapsed since initial call
to libburn was 45683 microseconds.

The commands are specified in SCSI documents SPC, MMC, and SBC.

growisofs has no such logging facility. But back in 2009 i augmented a
local copy of it by logging functionality from libburn.

If you are interested, it's about 150 lines of code. Mostly one piece
which defines two methods. Plus two method calls in method transport().
You'd have to put that code into a local copy of dvd+rw-tools source and
build the programs from that.

Then i will possibly be able to make a new thory from such a (very verbose)
log.

> I feel that this is a bug in growisofs with this specific drive.

Well, i transplanted that logging facility because growisofs was able
to burn on a particular drive with 16x DVD speed, whereas libburn suffered
from periodic throughput weakness.
After i spent two days with the problem, the situation suddenly turned
around. growisofs stumbled, libburn became fluent. I never found out what
was wrong with that drive. It belonged to a user who wanted it back.

So to my experience: Yes, the drive is peculiar.
But the rest is still unclear.

Have a nice day :)

Thomas

[Ryan C. Underwood (nemesis-icequake)]

On Thu, Mar 22, 2018 at 07:09:56PM -0000, Thomas Schmitt wrote:
>
> growisofs has no such logging facility. But back in 2009 i augmented a
> local copy of it by logging functionality from libburn.
>
> If you are interested, it's about 150 lines of code. Mostly one piece
> which defines two methods. Plus two method calls in method transport().
> You'd have to put that code into a local copy of dvd+rw-tools source and
> build the programs from that.
>
> Then i will possibly be able to make a new thory from such a (very verbose)
> log.

Sure, can you place the patch somewhere and also let me know what
upstream version to apply against?

--
Ryan C. Underwood, <email address hidden>

[Thomas Schmitt (scdbackup)]

Hi,

attached is a patch which enables SCSI logging to stderr in dvd+rw-tools.
It is based on dvd+rw-tools-7.1.tar.gz (MD5 8acb3c885c87f6838704a0025e435871).

There is no run-time control for this feature yet. Define or undefine
macro Libburnish_scsi_log_to_stderR and run "make" to enable or
disable the logging.

I tested it roughly by

  $ ./dvd+rw-mediainfo /dev/sr0

  INQUIRY
  12 00 00 00 24 00
  From drive: 36b
  05 80 00 32 5b 00 00 00 41 53 55 53 20 20 20 20 42 57 2d 31
  36 44 31 48 54 20 20 20 20 20 20 20 31 2e 30 31
       4 ms
  INQUIRY: [ASUS ][BW-16D1HT ][1.01]

  TEST UNIT READY
  00 00 00 00 00 00
  +++ key=2 asc=3Ah ascq=01h ( 16 ms)

  MODE SENSE
  5a 08 2a 00 00 00 00 00 24 00
  From drive: 36b
  00 4a 70 00 00 00 00 00 2a 42 3f 37 f1 77 29 23 21 14 01 00
  0f e0 21 14 00 10 21 14 21 14 00 01 00 00 00 00
       4 ms

  MODE SENSE
  5a 08 2a 00 00 00 00 00 4c 00
  From drive: 76b
  00 4a 70 00 00 00 00 00 2a 42 3f 37 f1 77 29 23 21 14 01 00
  0f e0 21 14 00 10 21 14 21 14 00 01 00 00 00 00 21 14 00 00
  00 00 21 13 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       8 ms

  GET CONFIGURATION
  46 01 00 00 00 00 00 00 08 00
  From drive: 8b
  00 00 00 9c 00 00 00 00
  From drive: 8b
  00 00 00 9c 00 00 00 00
       8 ms

  GET CONFIGURATION
  46 01 00 00 00 00 00 00 a0 00
  From drive: 160b
  00 00 00 9c 00 00 00 00 00 00 03 48 00 43 00 00 00 42 00 00
  00 41 00 00 00 40 00 00 00 2b 00 00 00 1b 00 00 00 1a 00 00
  00 16 00 00 00 15 00 00 00 14 00 00 00 13 00 00 00 12 00 00
  00 11 00 00 00 10 00 00 00 0a 00 00 00 09 00 00 00 08 00 00
  00 02 00 00 00 01 0b 08 00 00 00 07 01 00 00 00 00 02 07 04
  02 00 00 00 00 03 0b 04 39 00 00 00 01 00 03 00 01 05 07 04
  00 00 00 00 01 08 03 0c 4b 39 43 46 39 32 41 35 30 31 32 20
  01 0c 03 10 32 31 31 33 30 32 30 35 31 39 33 30 20 20 00 00
       8 ms
  GET [CURRENT] CONFIGURATION:
  :-( no media mounted, exiting...

The time measurement is the coarse one from the SG_IO transaction.
One could improve this patch by importing the newer time measuring
code from libburn/spc.c function scsi_log_reply():

       fprintf(fp, " %8.f us [ %.f ]\n",
               duration * 1.0e6,
               (burn_get_time(0) - lib_start_time) * 1.0e6);

But purchasing the necessary parameters is not totally trivial and i
will probably get to doing it soon.

Have a nice day :)

Thomas

[Thomas Schmitt (scdbackup)]

Urm. The last stement should have been:
"... i will probably _not_ get to doing it soon."

[Thomas Schmitt (scdbackup)]

... and there is a copy+paste error with
{{{
  GET CONFIGURATION
  46 01 00 00 00 00 00 00 08 00
  From drive: 8b
  00 00 00 9c 00 00 00 00
  From drive: 8b
  00 00 00 9c 00 00 00 00
       8 ms
}}}
Of course, the drive replied only once.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "This patch enables SCSI logging to stderr in dvd+rw-tools" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Ryan C. Underwood (nemesis-icequake)]

no DAO option

[Ryan C. Underwood (nemesis-icequake)]

dao option

[Ryan C. Underwood (nemesis-icequake)]

Attaching logs for
./growisofs -Z /dev/dvdrw=dvd.iso (nodao.log)
./growisofs -use-the-force-luke=dao -Z /dev/dvdrw=dvd.iso (dao.log)

The difference in the actual commands sent seems to be stark.

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?

[Thomas Schmitt (scdbackup)]

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