Bugzilla Bug 184783

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 an attachment (id=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] [details]
> 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 an attachment (id=126248) [details]
diff between original and patched ebuild

hope I have done this correct...

Fixed in 1.0.20070814.  Thanks, Tobias