Re: [Libcdio-devel] Fedora bug report concerning CD-TEXT

[Thomas Schmitt]

Hi.

Rocky Bernstein wrote:
> Sure, change mmc as given above, and add a routine to try
> the 2-step approach if that's the way you think best.

That's a larger task. One should check all usages of SCSI commands
if they may have variable reply length.
But let's first see how beneficial such a change would be.


Currently we are riddling why READ SUB-CHANNEL lets libcdio
deliver two different track ISRC listsi on two tries on two
different drives. In each of the lists, the ISRC of one track
is repeated for the next one.

TRACK  7 ISRC: QMWT21600007
TRACK  8 ISRC: QMWT21600008
TRACK  9 ISRC: QMWT21600008
TRACK 10 ISRC: QMWT21600009

TRACK  7 ISRC: QMWT21600007
TRACK  8 ISRC: QMWT21600007
TRACK  9 ISRC: QMWT21600008
TRACK 10 ISRC: QMWT21600009

Possible reasons would be:

- Linux transport problems if the requested transfer length is
  larger than the number of actually transferred bytes.
  (libburn and cdrtools once had to follow the habits of
   dvd+rw-tools because Linux USB drivers failed if too many
   bytes were requested.)

  I propose to reduce buffer size to 24 in order to request
  only as many bytes as promised by MMC-4, the last standard
  version which describes READ SUB-CHANNEL.

- Some confusion inside libcdio about the attribution of ISRC
  to the particular track.
  But there is only a simple loop around READ SUB-CHANNEL
  and the command gets the loop counter as track number parameter.
  Hard to imagine how this could go wrong if READ SUB-CHANNEL
  would properly succeed.

  More eyes might find more than i can see.

- Unnoticed transport or MMC error.
  The reply buffer is not set to 0 completely. If (deprecated)
  ioctl(CDROM_SEND_PACKET) does not properly indicate error then
  then the ISRC of the previous track could survive and be
  attributed to the track where the command failed.

  I propose to memset the whole buffer to 0, in order to prevent
  previous data from popping up again.

The proposals currently go mainly to James Olin Oden, because
i cannot yet reproduce the problem here.
The "more eyes" proposal goes to anybody who is interested
in the problem.


Have a nice day :)

Thomas