Hi there, I have already described the problem in the linked URL. It's basically a problem with the (old and somehow broken) cdparanoia library, that is internally used by mplayer for digital audio extraction, and therefore CDDA playback. The problem is that if you use the new kernel ATA layer then every optical device shows up as SCSI device and you have to use the sg devices to get cdparanoia (and also mplayer) to work with the drive. The sr devices won't work. But cdparanoias technique of getting data from the scsi produces TONS of kernel log messages, mainly by incorrectly using the interface. Now the libcdio project also supplies a paranoia tool, named cd-paranoia (when libcdio is emerged it's named libcdio-paranoia). What I request: the mplayer ebuilds should include libcdio support (maybe by USE flag) and remove the --disable-libcdio parameter that is passed to configure by default. cdparanoia should not be used anymore. It is old, broken and unmaintained. I think this should solve a LOT of problem, especially when more people switch to the new ATA layer and experience the same problem when playing audio discs through digital extraction (IIRC there a only a few libraries that actually do this). Maybe you also should add a warning message to the ebuild when cdparanoia and not libcdio is used, but that would be secondary. Thanks, Tobias Jakobi Reproducible: Always Steps to Reproduce: 1. use new ATA layer in kernel, raw access to cdrom with sg devices 2. build mplayer with cdparanoia support (otherwise cdda support isn't avail) 3. playback normal audio cd and watch kernel log growing Actual Results: It floods the kernel log Expected Results: no output to the kernel log at all while extracting digital audio data from teh drive
Apparently mplayer also needs cddb support when building with libcdio (cdparanoia disabled). I don't know if this is related to the enabled cdda USE flag of libcdio, but I'm going to check this later.
OK, I did find some time to check this and write a modified ebuild version. The use of cddb functions doesn't seem to depend on whether libcdio is build with cddb or not, so if libcdio support is enabled then also cddb support should be present. I modified (and attached) the ebuild so it checks for libcdio if the cdio useflag (new one) is enabled. If enabled libcdio is prefered over cdparanoia (even when cdparanoia use flag is on) and when building with libcdio it always build with cddb (I didn't have to modify anything for cddb because there seem to be no lib dependencies). One think I have to add: Although no stable version was released in quite some time the cdparanoia project seems to be maintained and the latest version from SVN (cdparanoia III 10pre0) builds absolutely fine on my system and produces no kernel flooding. It uses the new SG_IO interface instead of the old SG. The only problem the maintainer mentioned was some trouble with SATA optical drives, but he is not sure if current kernels have already sorted this out. So it might be a good idea to add the 3.10.pre0 to portage for testing. Thanks, Tobias
Created attachment 126234 [details] modified 1.0.20070622-r1 ebuild has added cdio useflag that enables usage of libcdio (preferred over cdparanoia)
(In reply to comment #3) > Created an attachment (id=126234) [edit] > modified 1.0.20070622-r1 ebuild > > has added cdio useflag that enables usage of libcdio (preferred over > cdparanoia) > can you do a diff instead of a new ebuild
Created attachment 126248 [details, diff] diff between original and patched ebuild hope I have done this correct...
Fixed in 1.0.20070814. Thanks, Tobias
