Re: [Libcdio-devel] Re: DVD problems.

[Rocky Bernstein]

mmc_get_media_changed() should tell one if the media has changed since the
last call. I think a call to set the status is performed initially when
creating a CdIo object.

But there is no code inside the library which is using this to refresh
cached information. In fact, right now doing so would interfere with the
ability of the application to determine if the media has changed. So I guess
I need to cache a boolean media_changed which tracks when the
*application *last
asked about whether media has changed.

So the current thought has been to have a parameter on various calls which
forces specific information to get retrieved from the drive rather than
reused from cached information when it looks like using cached information
would otherwise be okay.

There is nothing in libcdio libraries that currently tries to determine
optical media type. So just write MMC-based code and we'll add that as a
user-visible routine.

On Sun, Feb 7, 2010 at 3:46 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> > My current thinking right now is to create a MMC object for all of the
> > cached information
>
> Is libcdio always aware when the media state
> changes ? So that it can discard invald cache
> parts and re-inquire them from the drive when
> the application asks for them.
>
> If not, then there should be an opportinity
> for the application to force re-inquiry.
> Maybe it knows better when not to trust the
> old cache info any more.
>
>
> > > [Media recognition]
> > > Give me a stub where to examine "DVD-ROM" and
> > > "BD-ROM". Map all other valid non-CD profiles
> > > to the appropriate CDIO_DISC_MODE_*.
> > > Invent new ones which for BD profiles.
>
> > So if I have the above correct, I think this has to wait until we have a
> way
> > to get and cache current profile information. Right?
>
> The planned call for profile inquiry would be
> used if it is available.
> But there is not much penalty in issueing a GET
> CONFIGURATION command to obtain the Current
> Profile directly from the drive.
>
> Sketch:
>
> - Call GET CONFIGURATION for Current Profile in
>  byte 6 and 7 of its reply
>
> - All profiles map directly to media types,
>  except:
>
>  - Invalid profile or CD profiles 0x08 - 0x0a
>    get handled by traditional libcdio code.
>
>  - Profiles 0x10 "DVD-ROM" and 0x40 "BD-ROM"
>    get examined by READ DISC INFORMATION Format
>    code 00h. The reply differs between DVD and
>    BD, but both have a 4-byte header before the
>    actually interesting data:
>
>    - DVD:
>      Disk Category in bits 4 to 7 of byte 0+4
>      gives the "Book Type". See table 400/401
>      in previous mail.
>      The book types and the DVD profiles are
>      not exactly the same thing. But if a DVD
>      says it is book type "DVD+R" then we can
>      expect that it appears as profile DVD+R in
>      a burner drive.
>
>    - BD:
>      Disc Type Identifier in bytes 8+4 to 10+4
>      is clear text :
>      BDO for BD-ROM, BDW for BD-RE, BDR for BD-R
>      (mmc5r03c.pdf,
>       Table 448 - General DI Unit Format.
>       I wrote a wrong statement about this being
>       in 108+4 to 110+4.)
>      This does not distinguish the two possible
>      BD-R profiles. Assume SRM, if distinction
>      of BD-R SRM and BD-R RRM is desired at
>      all.
>
> So the MMC part would be quite clear.
> What i cannot do yet, is to identify the places
> in the code where this examination shall happen.
>
> Which parts of libcdio are currently determining
> media types ?
> How to do the sidestep into the new recognizer
> and how to decide whether that suffices or
> whether to dive into the old CD recognizer ?
>
>
> You could assume a magic recognizer and define
> its prototype and reply values.
> Then you write a recognizer dummy which always
> replies "don't recognize" and place its calls
> where needed.
> I would then put more brain into the dummy, so
> that it can say: "this is a DVD+R, regardless
> what the Current Profile states".
>
>
> Have a nice day :)
>
> Thomas
>
>
>
>