Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW

[Thomas Schmitt]

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