Sound Juicer

Bug #42752
Comment #4

Comment 4 for bug 42752

Revision history for this message

over 5000 (over5000-deactivatedaccount) wrote on 2008-07-17:

I think the problem here is not that Sound Juicer "sometimes" detects the right drive.
It does not.
Instead, it always uses the one selected in the settings dialog.

[Wishlist for a better world]I think there should not be such a setting at all!
Most of the time Sound Juicer is only started for a specific device.
For it to be run from the menu - and only if there's no way to implement auto detection - there should be a device select box and a "go read this device's audio tracks" button next to it - probably right below the menu bar in the main window, since that would be the first thing to select in a normal CD ripping workflow with no preselected device.
Instead, now, clueless users need to search the Settings dialog, before they can start any action if not by accident the correct device is selected right from the start.[/Wishlist for a better world]

To reproduce this bug with two cd drives, A and B.

- Select drive A in the sound juicer settings. Close sound juicer.
- Insert a disk in drive A.
Result: sound juicer fires up and displays the track list of the inserted CD.
- Now close sound juicer.
- Eject the CD from drive A
- Put it into drive B.
Result: sound juicer is launched again, but no tracks are shown. There is nothing giving any clue as to why the title list isn't shown.
- Open the Settings dialog to find out that drive A is selected and you need to change it to drive B.
Result: the tracks of the CD in drive B are finally shown.

Reproducible with /desktop/gnome/volume_manager/autoplay_cda_command = "sound-juicer -d %d"

Interestingly, "ps aux | grep sound" shows sound-juicer as started without any arguments ("sound-juicer"), instead of, like defined in gconf, as "sound-juicer -d /dev/sXXn". So the actual bug might be somewhere else.
Running "sound-juicer -d /dev/scd0" from the terminal, with /dev/scd0 being drive B from above (the one not selected in the settings dialog), starts sound juicer with the track list in display, as it should be.

Should I file a new bug? If yes, where? Which package handles the auto play features?

I think the problem here is not that Sound Juicer "sometimes" detects the right drive.
It does not.
Instead, it always uses the one selected in the settings dialog.

[Wishlist for a better world]I think there should not be such a setting at all! 
Most of the time Sound Juicer is only started for a specific device. 
For it to be run from the menu - and only if there's no way to implement auto detection - there should be a device select box and a "go read this device's audio tracks" button next to it - probably right below the menu bar in the main window, since that would be the first thing to select in a normal CD ripping workflow with no preselected device.
Instead, now, clueless users need to search the Settings dialog, before they can start any action if not by accident the correct device is selected right from the start.[/Wishlist for a better world]

To reproduce this bug with two cd drives, A and B.

- Select drive A in the sound juicer settings. Close sound juicer.
- Insert a disk in drive A.
Result: sound juicer fires up and displays the track list of the inserted CD.
- Now close sound juicer.
- Eject the CD from drive A
- Put it into drive B.
Result: sound juicer is launched again, but no tracks are shown. There is nothing giving any clue as to why the title list isn't shown.
- Open the Settings dialog to find out that drive A is selected and you need to change it to drive B. 
Result: the tracks of the CD in drive B are finally shown.

Reproducible  with /desktop/gnome/volume_manager/autoplay_cda_command = "sound-juicer -d %d"

Should I file a new bug? If yes, where? Which package handles the auto play features?