Re: [Libcdio-devel] Read Sub-channel changes

[Rocky Bernstein]

Thanks for the detailed investigation and analysis.

One should consider to give up the ioctl because mmc_get_mcn()
> can indicate whether the result is valid.
>

Sure, at this point we should use mmc_get_mcn(). There was a time didn't
exist, and then was flaky, and the ioctl's were both easy and, back then,
more reliable as they handled drives that didn't support MMC.

Those days however are long gone, so it is time to change.

On Tue, May 31, 2016 at 11:40 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> the difference in behavior between 0.93 and git was incidential.
>
> ---------------------------------------------------------------------
> New observations:
> ---------------------------------------------------------------------
>
> With the problem CD it is quite random whether TRACK 1 and/or TRACK 3
> are reported. TRACK 2 is never reported.
>
> The missing tracks get omitted, because the TCVAL bit is not set in
> the reply data from the drive. 24 bytes get returned, though.
> If i set this bit in order to print the received ISRC, i get
> "000000000000".
>
> ---------------------------------------------------------------------
>
> MCN is not inquired via mmc_get_track_isrc_private(). During the run
> of cd-info, it is not called with sub_chan_param == 2 for MCN. There
> are only the three calls with sub_chan_param == 3 for ISRC.
>
> The reason is that cd-info calls cdio_get_mcn(), which calls
> ((CdIo_t *) p_cdio)->op.get_mcn, which is set to get_mcn_linux()
> in cdio_open_am_linux().
> get_mcn_linux() calls ioctl(CDROM_GET_MCN) rather than mmc_get_mcn().
>
> One should consider to give up the ioctl because mmc_get_mcn()
> can indicate whether the result is valid. The ioctl returns 0, so that
> the value "00...00" cannot be distinguished from a valid one.
>
> This change could be done in cdio_get_mcn(). I.e. i would give up the
> function pointer ((CdIo_t *) p_cdio)->op.get_mcn, because it gets
> ((CdIo_t *) p_cdio)->env whereas mmc_get_mcn() wants (CdIo_t *).
>
> I am testing this now. mmc_get_mcn_isrc_private() gets called with
> sub_chan_param = 2. Available length is 24. MCVAL bit in the reply
> is not set.
>
> ---------------------------------------------------------------------
>
> The first CD-RW which i tested, reliably returns a non-0 MCN and all
> three ISRCs.
>
> ---------------------------------------------------------------------
> Current theory:
> ---------------------------------------------------------------------
>
> The drive has problems to read the MCN and ISRC of the problem CD.
> It quite often succeeds with track 1 and 3. Never with track 2 or MCN.
> By lack of MCVAL/TCVAL bit it correctly indicates the failure.
> It does not indicate error by Sense Code, though.
>
> (Regrettably this does not explain the ISRC glitch shown in
>   https://bugzilla.redhat.com/show_bug.cgi?id=1321677#c8
> )
>
> The changing read success makes me believe that libburn's way of
> burning the CD-RW is not to blame. It rather looks like a problem between
> drive and medium.
>
> ---------------------------------------------------------------------
>
> Have a nice day :)
>
> Thomas
>
>
>