Bug 457185 - Internal cdparanoia ripper does not work
Internal cdparanoia ripper does not work
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: grip (Show other bugs)
9
i386 Linux
low Severity low
: ---
: ---
Assigned To: Adrian Reber
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-30 01:43 EDT by Stefan Becker
Modified: 2009-03-05 13:31 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-05 13:31:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace log from ripper subprocess (1.10 KB, text/plain)
2008-08-10 12:41 EDT, Stefan Becker
no flags Details

  None (edit)
Description Stefan Becker 2008-07-30 01:43:54 EDT
Description of problem:
The internal cdparanoia ripper does not extract any data. External rippers still
work, but grip does not display quality status from external rippers.

Version-Release number of selected component (if applicable):
grip-3.2.0-19.fc9

How reproducible:
Always

Steps to Reproduce:
1. Configure grip to use internal cdparanoia ripper
2. rip only
3.
  
Actual results:
The ripper does not create any files.

Expected results:
Data is ripped from the audio CD

Additional info:
The status window doesn't show any errors. I tried "strace -ff -o grip.log
grip". Here is a log from one of the rip processes:

set_robust_list(0xb5093be0, 0xc)                               = 0
getpriority(PRIO_PROCESS, 0)                          = 20
setpriority(PRIO_PROCESS, 0, 0)                                  = 0
getpriority(PRIO_PROCESS, 0)            = 20
dup(23) = 24
fcntl64(24, F_GETFL) = 0x1 (flags O_WRONLY)
fstat64(24, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fe1000
_llseek(24, 0, 0xb5093164, SEEK_CUR)    = -1 ESPIPE (Illegal seek)
stat64("/dev/cdrom", {st_mode=S_IFBLK|0660, st_rdev=makedev(11, 0), ...}) = 0
write(24, "\n", 1)                      = 1
write(24, "Unable to open cdrom drive.\n", 28) = 28
close(24)                               = 0
munmap(0xb7fe1000, 4096)                = 0
futex(0xc0e140, FUTEX_WAKE_PRIVATE, 1)  = 0
_exit(0)                                = ?

Maybe the grip-internal cdparanoia source code needs to be updated to be able to
work correctly under F9?
Comment 1 Adrian Reber 2008-08-09 10:01:17 EDT
Sorry, works for me. I just ripped successfully a CD with the internal ripper. So I am tempted to close this as WORKSFORME.
Comment 2 Stefan Becker 2008-08-10 12:41:07 EDT
Created attachment 313893 [details]
strace log from ripper subprocess

Just tested it again. Still doesn't work. I also checked if it's a SELinux problem. But the problem also occurs with "setenforce 0".

The attached file shows a strace log from a rip subprocess. The sequence

pipe([18, 20]) = 0
dup(20)                               = 21
_llseek(21, 0, 0xb5225164, SEEK_CUR)              = -1 ESPIPE (Illegal seek)

Looks suspicious to me. Why does the code try to seek in the write-end of the pipe? Maybe you can compare this a strace log from your machine?
Comment 3 Christopher Beland 2009-03-05 11:37:09 EST
Just to be sure this isn't a hardware problem, are you able to successfully rip CDs from any other program?  If that works, does a complete removal and reinstall of grip fix anything?  It might be specific to your configuration, so moving those files aside temporarily and trying the default configuration could help diagnose the problem.
Comment 4 Stefan Becker 2009-03-05 13:31:17 EST
Before removing grip I first tried moving away my current grip configuration files and start with no configuration at all. Guess what: internal cdparanoia ripper works again!

I compared the old & new configurations and after going through the options that were different I found out that "force_scsi" was set to the wrong device. If I remember correctly an older Fedora release needed "/dev/cdrom" there. But now this needs to be either empty or point to the correct generic SCSI device ("/dev/sg1" in my case) or otherwise the internal cdparanoia ripper will do nothing.

So this is a user error and therefore the bug can be closed. I just wish there would have been a real error message pointing out the problem :-(

Note You need to log in before you can comment on or make changes to this bug.