Hi, Mauro Sacchetto wrote: > brasero -g --brasero-media-debug > log 2>&1
(After knowing the magic words i find man pages in the web which have it.) In the log from a successful Copy job with the Pioneer drive (sr1) i do not see the message about "TDB". But in the log of an immediate failure with the TAO CD in the ASUS drive, i see: BraseroMedia: (at brasero-drive.c:983) No medium inserted BraseroMedia: (at brasero-medium.c:1738) Following two sectors are readable. BraseroMedia: (at brasero-medium.c:1573) Checking for TDBs in track pregap. A problem with this log seems to be that the messages for both drives are intermixed without an indication which drive is meant. I assume that the "No medium inserted" is for empty sr1. So i cannot really tell from comparing both logs what triggers the TDB check on the ASUS or what prevents it on the Pioneer. But the Debian code search for "Following two sectors are readable" yields a suspect: https://sources.debian.org/src/brasero/3.12.3-1/libbrasero-media/brasero-medium.c/?hl=1738#L1738 The call brasero_medium_track_written_SAO() is made only if /* Test the last block, the before last and the one before before last */ result = brasero_mmc1_read_block (handle, ... yields result == BRASERO_SCSI_OK This seems to be true with the ASUS but not with the Pioneer. The log message immediately before "Following two sectors ..." is to see in both logs and seems to be falsely issued: BraseroMedia: (at brasero-medium.c:1715) Data track belongs to first session of multisession CD. Checking for real size (193536 sectors currently). Both logs have BraseroMedia: (at brasero-medium.c:2062) 2 track(s) found but the CD-RW is closed and has only one session with one track. If not the parameter "multisession" was set with the call of brasero_medium_track_get_info() then we possibly would not have this lengthy bug discussion. Well, i will know for sure only after i hacked libburn to issue such a READ CD command for sector number -1 with exactly the same CDB bytes as reported by dmesg: [20205.014237] ata3.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 5 Volume set (in), Read cd be 00 ff ff ff ff 00 00 01 10 00 00 res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout) If this experiment makes the drive stuck, then we have the culprit. Hmm ... i dimly remember a project to send SCSI commands from the shell. Google brings me to sg_raw of sg3-utils. Looks like we have it. https://manpages.debian.org/testing/sg3-utils/sg_raw.8.en.html Probably: sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 \ --outfile=tdb_data.bin I will explore this later this weekend. Have a nice day :) Thomas
