mkisofs $OPTS -V $1 $2|cdrecord driveropts=layerbreak=2086912 $COMCD2086912 blocks = 4076 MiBTrack 01: 4075 of 8124 MB written (fifo 99%) [buf 99%] 8.2x.cdrecord: faio_wait_on_buffer for writer timed out. cdrecord: Input/output error. write_g1: scsi sendcmd: no error CDB: 2A 00 00 1F D7 E9 00 00 1F 00 write track data: error after 4273948672 bytesThe "1F" in CDB means 31 blocks are to be written by this WRITE10 command.The "1F D7 E9" means write address is 2086889. (Confirmed by: 4273948672 / 2048 == 2086889) The write size of 31 blocks seems systematic: 2086889 % 31 == 0 The man page of cdrecord says: "The manual layer break value needs to be a mul- tiple of the ECC sector size which is 16 logical 2048byte sectors in case of DVD"2086912 - 2086889 == 23 The failing write command is 31 blocks long and thus touches both layers.
Couldn't agree more. The unit in question obviously crashes (power cycle is required to bring it back, i.e. reboot of unit) if write request crosses layer break position.
What I'd like to see is dvd+rw-mediainfo output for growisofs recording that failed at 98%. It should be noted that growisofs reserves for possibility of resuming DVD+R DL recording. If file set (or preformatted image) is not changed in any way, then in most cases it would be possible to re-run the exact command and complete recording. I'd also like to see output from beginning of failed growisofs recording... As always...
Rob and CJ: what are your magic layer break values which made cdrecord work on DVD+R DL ?
As far as I understood the default value reported by unit, the one that would be used if application didn't set layer break position. It sounds as if their units can't handle arbitrary layer break positions and has to be reminded about what it said itself. I don't think it's related... A.