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
