Bug 595812 - rrip_gui crashes and rrip_cli doesn't work correctly.
Summary: rrip_gui crashes and rrip_cli doesn't work correctly.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rubyripper
Version: 13
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Felix Kaechele
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 602562
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-25 16:47 UTC by Lodegario Malpica
Modified: 2011-03-31 20:02 UTC (History)
3 users (show)

Fixed In Version: rubyripper-0.6.0-1.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-30 20:01:25 UTC
Type: ---
Embargoed:


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

Description Lodegario Malpica 2010-05-25 16:47:57 UTC
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 18:01:18 UTC
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 18:58:09 UTC
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 22:03:19 UTC
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 14:50:58 UTC
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 19:22:13 UTC
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 10:43:41 UTC
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 13:30:34 UTC
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>
/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 10:50:27 UTC
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 13:36:11 UTC
(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 09:39:03 UTC
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 09:39:13 UTC
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 09:39:21 UTC
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 20:01:07 UTC
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 20:02:47 UTC
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 20:02:46 UTC
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.