Bug 457185 - Internal cdparanoia ripper does not work
Summary: Internal cdparanoia ripper does not work
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: grip
Version: 9
Hardware: i386
OS: Linux
low
low
Target Milestone: ---
Assignee: Adrian Reber
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-30 05:43 UTC by Stefan Becker
Modified: 2009-03-05 18:31 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-03-05 18:31:17 UTC
Type: ---
Embargoed:


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

Description Stefan Becker 2008-07-30 05:43:54 UTC
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 14:01:17 UTC
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 16:41:07 UTC
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 16:37:09 UTC
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 18:31:17 UTC
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.