Hi, Andy Polyakov wrote: > The unit in question [Gregoire's] obviously crashes (power cycle is > required to bring it back, i.e. reboot of unit) if write request crosses > layer break position. > It sounds as if their [Rob's and CJ's] > units can't handle arbitrary layer break positions and has to be reminded
i wrote: > 2086912 - 2086889 == 23 > The failing write command [of cdrecord with Gregoire's drive] > is 31 blocks long and thus touches both layers. Joerg Schilling wrote: > It may be that this has been forgotten in cdrecord's code (it was planned ;-) > if it works with other drives, then other drives do not follow the worst > possible firmware documented by the MMC standard. So the current consolidated theory would be about like this: --------- Problem number 1: Rob and CJ have drives which do not like any other layer break address than the one which is their default. Thus growisofs and cdrecord fail if their automatically computed layer breaks get set. The remedy is to enforce the drive's default layer break address and override the programs' computations. (This would mean that cdrskin has no problem with those drives. I would appreciate confirmation.) --------- Problem number 2: Gregoire's drive does not like if cdrecord's 31-block aligned write command touches both layers together by a single write command. It seems not to have a general layer break setting problem, because growisofs with its automatic layer break and its 16-block aligned write commands only fails much after the layer break. (One could verify this therory by aligning the manual layer break to a multiple of 496.) --------- Problem number 3: Gregoire's drive has a yet obsure problem with drive-media compatibility which shows up with growisofs and cdrskin but not with Nero. I am still clueless what preparations Nero could do to increase that compatibility. If 496-alignment allows cdrecord to cross the layer break, then it would be interesting to see whether it has write errors, too. --------- 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). The same growisofs command works well with DVD+R and sequential DVD-RW. So the rigid size curb seems to be a speciality with the handling of DVD+R DL in growisofs. In a further attempt, cdrskin wrote the whole stream to DVD+R DL with no error messages. (The readability of the media was mediocre, though. I/o errors with several payload files. So the user went back to single layer media. Elsewise i would now advise him to set a maximum manual layerbreak by -use-the-force-luke=break:size ) ------------- Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
