First and foremost, thanks for the patch or more precisely the work gone to think about what is lacking and packaging how to fix it. It is rare libcdio gets patches.
[EMAIL PROTECTED] writes: > Hi all, > > I just updated gmerlin (http://gmerlin.sf.net/) for use of libcdio. > It's was really easy and everything works great so far (tested > analog audio playback and ripping via cdparanoia) I'm glad to hear that too. In the interest though of full disclosure, there seem to be recent problems noted when one uses libcdio's paranoia with a CD-ROM that has SCSI emulation. > except for one: > The linux driver detects CD Drives only, when a disk is in the > drive. Okay, I'll come clean with the sad truth. This project wasn't started from the standpoint of someone who knew a lot about CD-ROM's and the various kinds for formats on CD's, and what a library for such a best should look like. It came from the a simple and trivial observation that there was way too much cut and paste in the media players, not all that much abstraction either and a desire to try to add a little bit of abstraction and hopefully come up with the best of all of the cuts and pastes. (The rest has been a bit of a nightmare) So part of the reason at present GNU/Linux driver, and libcdio in general, detects only drives with CD's in them is two fold: first that's what was mostly useful in media players or say in the VCD programs (vcdxrip, vcd-info). Second, many Multimedia commands in the MMC set seem to make this assumption too - I don't know why. Or perhaps I just been able to fathom the available MMC drafts to figure out how say to get drive capabilities when a CD isn't loaded in a CD-ROM. But having witten all of this, I have realized that this was a deficiency and one that would have to eventually get addressed. The most recent in-my-face example of the deficiency was in the recent addition of audio controls and porting Gerd Knorr's cdda-player program. Here one should have the ability to close a CD-ROM tray. Rather than deal with the issue and libcdio design deficiency in the last release I decided it postpone it so as not to delay the other additions. But in the back of my mind there has been this reworking that probably needs to go on. You've been warned :-) And my current thought here, but as always I invite the opinions of others (and have burried this already far enough down that most people won't have read this far) is not to elimate the "detect CD-ROM with CD in it" function but also *add* the "detect CD-ROM with *or* *without* a CD in it. > I managed to track the problem down to 2 issues: > > 1. In the function is_cdrom_linux(...) in the file lib/driver/gnu_linux.c, > the CDROMREADTOCHDR ioctl gets called, which fails when the drive is > empty. The CDROM_GET_CAPABILITY ioctl always succeeds for CDrom drives > and fails for hard disks etc. Okay that's nice to know. Thanks for the info and tracking this down. > > 2. For some reasons, at least my (2.6.10) Kernel fails to open empty drives, > when only O_RDONLY is used. Changing the open flag to > O_RDONLY|O_NONBLOCK, the call succeeds also for emtpy drives. > By the way, the cdrom header file in the kernel says explicitely, > that O_RDONLY|O_NONBLOCK should used whenever a cdrom is touched. And this may touch on another can of worms and/or deficiency. There seems to be one camp that thinks that applications whould get CD-ROMs exclusive access and another that thinks one should be non-exclusive access. Right now libcdio seems to be in the non-exclusive access camp. But I have a feeling that as with the CD-ROM detection problem, libcdio may have to accomodate the other camp as well. And for the exclusive access CD-ROM situation where in GNU/Linux there is a flag for exclusive access and I suspect this might be used with O_BLOCK to block and wait for access. BEGIN YET ANOTHER DIGRESSION The exclusive access camp: - On Darwin, it seems one has to get exclusive access to issue arbitrary MMC - perhaps as a result of the above one of the OSX ports of cdparanoia gets exclusive access. Another and libcdio don't require exclusive access but I think they'll be able to do less. - I believe xine-lib uses exclusive access on say GNU/Linux - I think Peter Jones a Redhat cdparanoia indicated that RedHat suggests CD apps get exclusive access END OF YET ANOTHER DIGRESSION > > The attached patch against 0.73 (1) fixes the ioctl and (2) introduces > an additional flag argument for the function cdio_generic_init. The > linux driver will use O_RDONLY|O_NONBLOCK, the other drivers which use > this function (osx and solaris) use O_RDONLY to resemble the old behaviour > (I don't have access to these systems). Okay, will probably commit this after doing a bit of testing. It will probably cascade some changes on other OS's, I don't know. > > Please cc me, I'm not subscribed Done. _______________________________________________ Libcdio-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/libcdio-devel
