Bug 132888

of course the same applies to gnome-cd, etc., not only sound-juicer

1) Pretty sure this is fixed by 0.5.12, just uploaded to rawhide
2) I think this one might be fixed too
3) Mrmph.  udev.  I need to install a fresh rawhide system and
investigate that.

johnp and I talked about this a bit but we weren't sure - what's the
story with permissions for dynamically plugged in CD devices? 
Currently pam_console chowns the device when you log in, but that
isn't enough for devices plugged in after login.

Nalin, do you know?

David says the permissions fix was a udev bug, didn't make fc3t2, but
should work in the latest rawhide.

I've never used sound-juicer before on my system and 0.5.12 doesn't
work for me; I'm seeing issues 1. and 2. Specifically I'm getting this

[david@laptop ~]$ sound-juicer

** (sound-juicer:5029): WARNING **: Can't read /proc/scsi/sg/device_strs

** (sound-juicer:5029): WARNING **: Can't read /proc/scsi/sg/device_strs

However, udev-027 does fixes issue 3 and I can confirm udev-026
(shipped with test2) didn't.

After 'modprobe sg' as root, I get this

[david@laptop ~]$ sound-juicer
This CD could not be queried: Cannot open '/dev/hdd'

That's probably because my audio disc is in /dev/sdc0 which is my
external USB2.0 optical drive.

Hmm, when selecting the right drive in the preferences dialog of sj,
I'm getting this

[david@laptop ~]$ gconftool-2 --get /apps/sound-juicer/device
/dev/scd0
[david@laptop ~]$ sound-juicer
This CD could not be queried: Cannot open '/dev/hdd'

Inserting the drive into /dev/hdd and still having /dev/scd0 as the
preference makes ripping work.

latest udev should fix the dynamic cdrom permission issue and also sr0
-> scd0 renaming

I have:

[root@nexus walters]# rpm -q udev
udev-032-1

But my USB cdrom still shows up as /dev/sr0.

And I get a kernel oops unplugging it.  Whee, off to file that bug.

As for 2), it looks like sound-juicer stole some code to detect CD
devices which supports either HAL or linux-specific bits, and it just
uses the linux bits.  I'm trying to enable HAL now to see if that helps.

harald: nevermind, it is /dev/scd0, i was confused by dmesg saying it
was sr0.

Ok, this is a deep, deep mess.  I'm working with the latest
sound-juicer CVS which fixes some bugs, and I've got it using HAL to
pick up cdroms instead of the linux-specific grubbing, but this is all
for naught because apparently the latest cdparanoia doesn't understand
/dev/scd0.  This is bug #133312.

On my current system:
kernel-2.6.8-1.541
hal-0.2.98-4
udev-032-1
sound-juicer-0.5.12-1
cdparanoia-alpha9.8-21

I've just been rebooting a lot and to make things work I have to do
the following:
 - do not plug in the USB CD at boot time, or the kernel oopses;
   seems safe to plug it in after boot
 - MAKEDEV sg0
 - chmod hp.disk sg0

If I do those things then sound-juicer works fine. udev only creates
scd0 which as discussed above doesn't work.

This probably isn't helpful, but I thought I'd add the data point.

With Peter's modified cdparanoia, and the sound-juicer from CVS,
things work for me reasonably well.  I'm hoping Ross will do a new s-j
release soon, if not I'll just do a cvs snapshot.

Havoc, does your kernel oops look at all like this?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133249

Ok, I just built a new sound-juicer snapshot into rawhide,
sound-juicer-0.5.12.cvs20040927-1.  Havoc, could you try installing
Peter's cdparanoia-alpha9.8-21 RPM from the URL below and see if
things work for you?

http://people.redhat.com/pjones/cdparanoia/

This works for me, please reopen if you still have a problem.