So the current consolidated theory would be about like this: --------- Problem number 1: --------- Problem number 2: --------- Problem number 3: ---------
Agreed.
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).
3916389 % 16 = 5 or 32-27, so if recording was folded in the middle of iso image, then 27 would indeed be maximum possible padding (well, it could have been 16-5=11 if amount of ECC blocks in padded image would be even). Question is if above is actually complete growisofs command line? Point is that growisofs does *not* set layer break, if you don't pass -dvd-compat [or -dvd-video], and without it shouldn't be a problem to pad iso image with additional data... In other words, 'growisofs -Z /dev/...=/dev/fd/0' should have actually worked, while 'growisofs -dvd-compat /dev/...=/dev/fd/0' would work as described above.
Elsewise i would now advise him to set amaximum manual layerbreak by -use-the-force-luke=break:size
Yes. One can even argue that growisofs should recognize break:+size, which would reserve for size padding, as well as break:max... A.