Re: Fatal error while burning CD
Hi,
i am making theories how the drive firmware could perceive any illegal
request while WRITE(10) commands come in. (Senile dementia is not among
the usual signs of drive ageing. Rather they go blind or suffer stroke.)
I would be interesting to see the SCSI log of a failed dummy burn. I.e. with
option -V and redirection of text output to file cdrskin_scsi_log.
cdrskin -V ...your.options... 2>&1 | tee -i /tmp/cdrskin_scsi_log
If the failure happens, then the log will not be as large as with a
successful run, but nevertheless have a few hundred lines. So if you take
the plight on you to provoke the failure, then send the file to me in
private.
--------------------------------------------------------------------------
Vague theory i have:
The potential mistake of a burn program during data writing is that the
Logical Block Address of the WRITE(10) command does not match the data
stream count of the drive. Since libburn normally has no problem to compute
the apropriate LBA during data transmission, there would have to be a
misunderstanding about the number of accepted data blocks.
A drive is allowed to reply to WRITE(10) by ASC 04 "Logical unit not ready"
with some ASCQ number which indicates that the drive promises to become
ready without external intervention. The burn program is then supposed to
send again a WRITE(10) command with the same LBA and the same data payload.
This repetition is permissible only if the drive really did not count the
blocks of the previous WRITE(10) command.
Not many drives emit "not ready" when their buffer becomes full. Among mine
it's only the Optiarc BD-5300S.
The others simply wait with their reply to WRITE(10) until enough room is
in their buffer to take the next chunk of data.
The SCSI log of a failed run would show the LBAs of the WRITE(10) commands
and the possible "not ready" replies by the drive. Maybe i can learn how
libburn and drive came out of sync.
Have a nice day :)
Thomas
Reply to: