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
