Bug 457185
| Summary: | Internal cdparanoia ripper does not work | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Stefan Becker <chemobejk> | ||||
| Component: | grip | Assignee: | Adrian Reber <adrian> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 9 | CC: | beland | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-03-05 18:31:17 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Sorry, works for me. I just ripped successfully a CD with the internal ripper. So I am tempted to close this as WORKSFORME. 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?
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. 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 :-(
|
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?