Bug 595812 - rrip_gui crashes and rrip_cli doesn't work correctly.
rrip_gui crashes and rrip_cli doesn't work correctly.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: rubyripper (Show other bugs)
13
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Felix Kaechele
Fedora Extras Quality Assurance
:
Depends On: 602562
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-25 12:47 EDT by Lodegario Malpica
Modified: 2011-03-31 16:02 EDT (History)
3 users (show)

See Also:
Fixed In Version: rubyripper-0.6.0-1.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-30 16:01:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
error in rrip_cli. (17.64 KB, text/plain)
2010-05-25 12:47 EDT, Lodegario Malpica
no flags Details

  None (edit)
Description Lodegario Malpica 2010-05-25 12:47:57 EDT
Created attachment 416451 [details]
error in rrip_cli.

Description of problem:
When you try to run rrip_gui the window of rubyripper appears but it freezes, it gives a message in the window that is scanning for a disc, but it does nothing.
 
rrip_cli seems to work but it falls in a loop. It seems that it is not
reading the preferences file because in GUI I have configured to rip all tracks in a single one creating a cue sheet, and it seems trying to rip the whole track a number of times depending on how many tracks are in the album (see the attachments).

However if you select only one track it seems to work. I call this a bug
attachment).

Version-Release number of selected component (if applicable):
0.5.7

How reproducible:
running from a terminal $rrip_gui

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:
In rrip_gui to notice the presence of a disc, go to CDDB and rip the disc.
In rrip_gui that rip only one file, it doesn't matter you select all tracks, because you have a configuration file.

Additional info:
Maybe it is related with last ruby packages update
Comment 1 Felix Kaechele 2010-05-25 14:01:18 EDT
I will try to reproduce this as soon as I get home where I have my docking station with an optical drive to test.
Comment 2 Lodegario Malpica 2010-05-25 14:58:09 EDT
I have received the following message from the rubyripper site (http://code.google.com/p/rubyripper/issues/detail?id=417)

"The 0.5.7 version is not supported anymore. It's known to break in a lot of ugly
ways, especially when combined with ruby-1.9. You should try latest git version of
rubyripper. See the source tab for more info on this"

They are using 0.6.0 now, but if you can fix the error it will be appreciated, I don't know what rubyripper version will be in fedora 13, but I will be using fedora 12 some time.
Comment 3 Felix Kaechele 2010-05-25 18:03:19 EDT
It's kinda weird to stop supporting a release when no newer release is available. I think I'll update to the git version anyway as there seems no other easy way to fix this bug.
Comment 4 Lodegario Malpica 2010-05-31 10:50:58 EDT
I have try to use the git version of rubyripper (0.6.0) but I have the same problems and the developers argue that it is a distribution problem.
(http://code.google.com/p/rubyripper/issues/detail?id=417)
Comment 5 Poncho 2010-07-06 15:22:13 EDT
Rubyripper-0.6.0 is now the official release. The gui is still broken, I didn't try the client version.

There is another bug report here: http://code.google.com/p/rubyripper/issues/detail?id=433
Comment 6 Poncho 2010-07-17 06:43:41 EDT
This seems to be a ruby bug (https://bugzilla.redhat.com/show_bug.cgi?id=602562)

Rubyripper-0.6.0 is working fine (gui and cli) with ruby 1.8.7 p299. I installed and tried with the ruby rpms found here: http://mo.morsi.org/blog/node/322
Comment 7 Lodegario Malpica 2010-07-21 09:30:34 EDT
I have tried Rubyripper-0.6.0 with ruby 1.8.7 p299 but the GUI doesn't work with the option "rip the CD to a single file". the TOC analysis seems good, it creates the cue sheet, but after ripping the two cdparanoia images it seems to look for mismatched chunks but it dies. I have tried without extra cdparanoia settings and passing the -Z option and I get the same results. It never begin the flac codification and the log finishes with rubyripper looking for mismatched chunks.

The messages that appear in the terminal are:

nespino@starbux rubyripper]$ ./rubyripper_gtk2.rb &
[1] 21031
[nespino@starbux rubyripper]$ No disc found at trial 1!
No disc found at trial 2!
No disc found at trial 3!
No disc found at trial 4!
No disc found at trial 5!
No disc found at trial 6!
No disc found at trial 7!
scanning disc with cdrdao
Cdrdao version 1.2.3 - (C) Andreas Mueller <andreas@daneb.de>
/dev/cdrw: TSSTcorp DVD+-RW TS-H653A	Rev: D500
Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000)

Reading toc data...

Track   Mode    Flags  Start                Length
------------------------------------------------------------
 1      AUDIO   2      00:00:00(     0)     10:36:04( 47704)
 2      AUDIO   2      10:36:04( 47704)     07:28:00( 33600)
 3      AUDIO   2      18:04:04( 81304)     08:42:37( 39187)
 4      AUDIO   2      26:46:41(120491)     05:53:52( 26527)
 5      AUDIO   2      32:40:18(147018)     10:22:57( 46707)
 6      AUDIO   2      43:03:00(193725)     08:12:67( 36967)
 7      AUDIO   2      51:15:67(230692)     07:26:14( 33464)
Leadout AUDIO   0      58:42:06(264156)

PQ sub-channel reading (audio track) is supported, data format is BCD.
Raw P-W sub-channel reading (audio track) is supported.
Cooked R-W sub-channel reading (audio track) is supported.
Analyzing track 01 (AUDIO): start 00:00:00, length 10:36:04...
/home/nespino/lossless/Long Distance Calling (2007) Satellite Bay/flac
Long Distance Calling - Satellite Bay.flac
status = true
Found 10 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 02 (AUDIO): start 10:36:04, length 07:28:00...
Found 54 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 03 (AUDIO): start 18:04:04, length 08:42:37...
Found 2 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 04 (AUDIO): start 26:46:41, length 05:53:52...
Found 4 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 05 (AUDIO): start 32:40:18, length 10:22:57...
Found 16 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 06 (AUDIO): start 43:03:00, length 08:12:67...
Found 8 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Analyzing track 07 (AUDIO): start 51:15:67, length 07:26:14...
Found 13 Q sub-channels with CRC errors.
Control nibbles of track match CD-TOC settings.
Found CD-TEXT data.
        	
Reading of toc data finished successfully.
Loading file: /tmp/temp_cdrw.toc
Disc type = CD_DA
Found cd_text for disc
Found artist for disc: ""
Found album for disc: 
Found info of tracknumber 1
CD-text found: Title = LP
Found info of tracknumber 2
CD-text found: Title = LP
Found info of tracknumber 3
CD-text found: Title = LP
Found info of tracknumber 4
CD-text found: Title = LP
Found info of tracknumber 5
CD-text found: Title = LP
Found info of tracknumber 6
CD-text found: Title = LP
Found info of tracknumber 7
CD-text found: Title = LP
Debug info: gaps are now prepended
Startsector	Lengthsector
0	47704
47704	33600
81304	39187
120491	26527
147018	46707
193725	36967
230692	33464
Ripping image
Expected filesize for image		is 621294956 bytes.
Free disk space is 90548888 MB
Minutes ripping is 0.00039465.
cdparanoia [.0]- -d /dev/cdrw -O 6 "/home/nespino/lossless/Long Distance Calling (2007) Satellite Bay/temp_sr1/image_1.wav"
cdparanoia III release 10.2 (September 11, 2008)

Ripping from sector       0 (track  1 [0:00.00])
	  to sector  264155 (track  7 [7:26.13])

outputting to /home/nespino/lossless/Long Distance Calling (2007) Satellite Bay/temp_sr1/image_1.wav

 (== PROGRESS == [                              | 264155 00 ] == :^D * ==)   

Done.


Minutes ripping is 5.42090496666667.
cdparanoia [.0]- -d /dev/cdrw -O 6 "/home/nespino/lossless/Long Distance Calling (2007) Satellite Bay/temp_sr1/image_2.wav"
cdparanoia III release 10.2 (September 11, 2008)

Ripping from sector       0 (track  1 [0:00.00])
	  to sector  264155 (track  7 [7:26.13])

outputting to /home/nespino/lossless/Long Distance Calling (2007) Satellite Bay/temp_sr1/image_2.wav

 (== PROGRESS == [                              | 264155 00 ] == :^D * ==)   

Done.

Then it freezes. I waited for two hours and it stay in the same state.

The settings are:

flacsettings=--best -V
vorbissettings=-q 4
naming_various=%va (%y) %b/%a (%y) %b/
minLengthHiddenTrack=2
req_matches_all=2
preEmphasis=sox
wav=false
max_tries=3
naming_normal=%a (%y) %b/%f/%a - %b/
freedb=true
req_matches_errors=3
gain=album
pregaps=append
freedbCache=/home/nespino/.cache/rubyripper/freedb.yaml
noCapitals=false
verbose=true
username=anonymous
editor=gedit
mp3=false
maxThreads=2
noSpaces=false
cdrom=/dev/cdrw
first_hit=true
normalize=false
gainTagsOnly=false
other=false
playlist=true
site=http://freedb.freedb.org/~cddb/cddb.cgi
create_cue=true
mp3settings=-V 3 --id3v2-only
othersettings=
basedir=/home/nespino/lossless
naming_image=%a (%y) %b/%f/%a - %b/
debug=true
eject=true
ripHiddenAudio=true
hostname=my_secret.com
filemanager=nautilus --no-desktop
browser=firefox
no_log=false
rippersettings=
image=true
flac=true
vorbis=false
offset=6

At least the CLI works, then the problem could be in the program that links gtk with ruby.
Comment 8 Felix Kaechele 2010-07-25 06:50:27 EDT
If someone wants to test some new RPMs you can find them here:
http://heffer.fedorapeople.org/rubyripper/

Also see http://code.google.com/p/rubyripper/issues/detail?id=433

I have no idea how I could contribute to fix this bug and hope that it is resolved upstream, as it is most likely an upstream bug.
Maybe Fedora's ruby stack doesn't play nice with rubyripper.
Comment 9 Poncho 2010-10-16 09:36:11 EDT
(In reply to comment #3)
> It's kinda weird to stop supporting a release when no newer release is
> available. I think I'll update to the git version anyway as there seems no
> other easy way to fix this bug.

Do you consider updating rubyripper to 0.6.0 or to git version for Fedora 14?

(In reply to comment #8)
> If someone wants to test some new RPMs you can find them here:
> http://heffer.fedorapeople.org/rubyripper/

I tried to rebuild your src.rpm on f14 and get the following error:

Testing support for the graphical frontend...
/usr/lib/ruby/site_ruby/1.8/gtk2.rb:13:in `init': Cannot open display:   (Gtk::InitError)
Comment 10 Fedora Update System 2011-03-19 05:39:03 EDT
rubyripper-0.6.0-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/rubyripper-0.6.0-1.fc14
Comment 11 Fedora Update System 2011-03-19 05:39:13 EDT
rubyripper-0.6.0-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/rubyripper-0.6.0-1.fc13
Comment 12 Fedora Update System 2011-03-19 05:39:21 EDT
rubyripper-0.6.0-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/rubyripper-0.6.0-1.fc15
Comment 13 Fedora Update System 2011-03-30 16:01:07 EDT
rubyripper-0.6.0-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 14 Fedora Update System 2011-03-30 16:02:47 EDT
rubyripper-0.6.0-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Fedora Update System 2011-03-31 16:02:46 EDT
rubyripper-0.6.0-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

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