[openbeosstorage] Re: R5 Pro CD vs. partition/intel

> > > If it were just some random, obscure CD, I might be tempted to 
> > > say
> > > "screw it", but being the R5 Pro CD, we really ought to get the 
> > > thing
> > > working properly. Since I believe the updated cdrom module is
> > > actually working correctly, I've gone ahead and checked it in so
> > > everyone can play with it. :-)
> > 
> > Unfortunately, it doesn't seem to work for me. I just updated to 
> > the
> > latest CVS and the session module doesn't like the TOC or whatever.
> > BTW, I'm have a version distributed by Gobe. Don't know if it is 
> > the
> > same one distributed in the USA. Debug output is attached.
> 
> I have the Gobe one as well, but it appears to be ever so slightly 
> different: the toc entry 0xA0, which tells what the track # of the 
> first track in the session is, is marked as belonging to an audio 
> track; all other entries are correctly labeled as being data tracks. 
> I've updated the module to ignore such deviations now.

Great, now it crashes very nicely. ;-) Seems indeed to be some stupid 
bug in the cache code.

[...]
> > > And while I'm thinking of it, that special case to handle CDs in
> > > disk_scanner_get_nth_session_info() kind of bugs me. Oughtn't we 
> > > have
> > > a non-cdrom session module to handle the virtual session case, 
> > > and
> > > then allow developers to have a higher priority custom module in 
> > > the
> > > odd case that they want to support a special kind of session for
> > > their device? As it currently stands, only CD devices ever get a
> > > chance to publish sessions to the system.
> > 
> > That's true. If the session add-ons are robust enough, we can drop 
> > the
> > check for CD devices and return a virtual session, in case no 
> > session
> > add-on recognizes the format -- similarly as done on the partition
> > module level. We don't need to introduce a dummy session add-on to 
> > do
> > this -- otherwise we would indeed need priorities (not that I have
> > arguments against priorities, but we don't need to introduce 
> > something
> > we won't quite likely ever use).
> 
> Sounds much better to me.

Then I'll adjust it according.

CU, Ingo

Other related posts: