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:
:-[ [EMAIL PROTECTED] 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 a
maximum 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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
