problems introduced in r226?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. run rr
2. check output in rip dir
3.

What is the expected output? What do you see instead?
Instead of some nice big wav files there is only one 0 byte wav.  The temp
dir is full of trial rips, but for some reason the final wav is getting put
in the right place.  this seems to start around r223.  also, sector based
ripping may have messed some things up.  when I try to rip it shows the
sectors correctly but claims it will rip from 0:00.00 to 0:00.00 which is
obviously wrong.

What version of rubyripper are you using? On what operating system? Are you
using the gtk2 or the commandline interface?
rr r223-r261 have these issues for me.  gtk2 interface used. Running
Debian, of course.

Please provide any additional information below.
Possible libs are playing a role in this?  Debian updated some ruby libs
but they were minor version bumps, nothing drastic.

Original issue reported on code.google.com by mordbr...@gmail.com on 17 Jul 2008 at 7:54

[GoogleCodeExporter]

I've tried to do an image rip, and it resulted in no problems at all. I doubt 
the
problems should arise from an updated ruby itself. I've never come across any 
problem
with the upgrades in the past.

A few questions:
1) Are you using any special cdparanoia switches perhaps?
2) While ripping does the wav file grow?
3) How long does it take rubyripper to rip a disc + how long is the disc?
4) Does it happen on all discs or just on mixed mode cd's?
5) Do you have write access on the place you want to rip to?
6) Please post your settings file ($HOME/.rubyripper/settings)

Original comment by rubyripp...@gmail.com on 18 Jul 2008 at 5:24

[GoogleCodeExporter]

I'm not doing image rips, but just tried one and disc is ripped twice & 
compared but
no final wav is put in the directory.  In a temp dir (inside the disc dir) 
there is
track0_1.wav and .cue and .log file in the disc dir.

1.  No special switches
2.  Yes, the trial wav file grows while ripping
3.  It takes the normal amount of time to rip, like it's ripping each track 
twice
(and indeed it does) but after comparison of the first track there is a 0 byte 
wav. 
Subsequent tracks fail to even get the 0 byte file, but they go through all the 
trial
rips.  The CD is about 35 minutes long.
4.  Haven't tried any mixed mode CDs yet
5.  Yes, write access available.
6.  $HOME/.rubyripper/settings
req_matches_all=2
naming_various=%f/%a (%y) %b/%n - %va - %t
vorbissettings=-q 4
flacsettings=--best
cd=#<Disc:0xb7a441e4>
edit=false
freedb=true
naming_normal=%f/%a (%y) %b/%n - %t
max_tries=5
wav=true
gain=album
req_matches_errors=5
editor=gedit
username=anonymous
verbose=true
maxThreads=1
mp3=false
normalize=false
first_hit=true
cdrom=/dev/hdd
create_cue=true
site=http://freedb2.org:80/~cddb/cddb.cgi
playlist=false
other=false
no_log=false
filemanager=unkown
hostname=my_secret.com
eject=true
instance=main
debug=false
naming_image=%f/%a (%y) %b/%a - %b (%y)
basedir=/Sjø/
othersettings=
mp3settings=-V 3
image=false
rippersettings=
offset=48
vorbis=false
flac=false

Original comment by mordbr...@gmail.com on 18 Jul 2008 at 5:50

[GoogleCodeExporter]

Can you set debug to true and restart rubyripper and try to rip again? That the 
temp
dir is not removed is probably meaning it's going wrong somewhere. When debug is
enabled it will crash the application and show the fault. Make sure you launch
rubyripper from a terminal to see the crash info.

Original comment by rubyripp...@gmail.com on 22 Jul 2008 at 5:25

[GoogleCodeExporter]

No crash, but this is the output.  Disc ejects gui freezes and that's it.

[jebediah@manger]-(~/src/rubyripper/svn)$ ./rubyripper_gtk2.rb 
This command will be used to query cdparanoia:
cdparanoia -d /dev/hdd -vQ 2>&1
This command will be used to query cdparanoia:
cdparanoia -d /dev/hdd -vQ 2>&1
Ripping track 8
cdparanoia III release 10.0 (June 10, 2008)

Ripping from sector  192565 (track  8 [0:00.00])
      to sector  222292 (track  9 [0:00.00])

outputting to /Sjø/wav/temp/track8_1.wav

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

Done.

cdparanoia III release 10.0 (June 10, 2008)

Ripping from sector  192565 (track  8 [0:00.00])
      to sector  222292 (track  9 [0:00.00])

outputting to /Sjø/wav/temp/track8_2.wav

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

Done.

Adding track 8 (wav) into the waitingroom..
Inside handleThreads: maxthreads = 1, threads = 0

Original comment by mordbr...@gmail.com on 31 Jul 2008 at 1:40

[GoogleCodeExporter]

No crash, but this is the output.  Disc ejects gui freezes and that's it.

[jebediah@manger]-(~/src/rubyripper/svn)$ ./rubyripper_gtk2.rb 
This command will be used to query cdparanoia:
cdparanoia -d /dev/hdd -vQ 2>&1
This command will be used to query cdparanoia:
cdparanoia -d /dev/hdd -vQ 2>&1
Ripping track 8
cdparanoia III release 10.0 (June 10, 2008)

Ripping from sector  192565 (track  8 [0:00.00])
      to sector  222292 (track  9 [0:00.00])

outputting to /Sjø/wav/temp/track8_1.wav

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

Done.

cdparanoia III release 10.0 (June 10, 2008)

Ripping from sector  192565 (track  8 [0:00.00])
      to sector  222292 (track  9 [0:00.00])

outputting to /Sjø/wav/temp/track8_2.wav

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

Done.

Adding track 8 (wav) into the waitingroom..
Inside handleThreads: maxthreads = 1, threads = 0

Original comment by mordbr...@gmail.com on 31 Jul 2008 at 1:41

[GoogleCodeExporter]

Latest commit might just solve your problem too I think. Maybe the issues were
related after all.

Original comment by rubyripp...@gmail.com on 4 Aug 2008 at 10:35

• Changed state: Accepted

[GoogleCodeExporter]

No joy, although the temp dir is now in the right place (and there is no 
duplicate of
it).   No wav is output in the album dir, the temp dir still isn't cleared.  rr 
still
hangs and spikes CPU after ejecting the disc.

Original comment by mordbr...@gmail.com on 4 Aug 2008 at 11:06

[GoogleCodeExporter]

I guess you are patient enough to let the encoding finish. What does the `top`
command show you when it 'hangs'? Which program is eating cpu?

Does this also happen if you just rip the first track?

Original comment by rubyripp...@gmail.com on 4 Aug 2008 at 11:31

[GoogleCodeExporter]

No encoding to be done as I leave output in wav... so after comparing the files 
and
outputting the checksum it should be done; that typically takes a few seconds 
on my
machine (unless the track is really long) and this is far longer before ctrl-c 
in the
term.  top shows that ruby is the cause of the cpu eating.  This still occurs 
if I
only rip the first track.

Something else to note: if I only rip one track there is a 0 byte wav in the 
album
dir.  If I rip more than one track there are no wav files in the album dir (but 
they
are in the temp dir).

The CPU hogging happens after the first comparison.  After that rr continues 
ripping
but the GUI is blank and it can only be closed by the window managers close 
button.

Could this have anything to do with any of it?
rr_lib.rb:875:in `rip': wrong number of arguments (0 for 1) (ArgumentError)

deadlock 0xb7d1b1b0: sleep:F(10) (main) - /usr/lib/ruby/1.8/glib2.rb:30
deadlock 0xa543a80: sleep:F(6)  - /usr/lib/ruby/1.8/fileutils.rb:1055
/usr/lib/ruby/1.8/fileutils.rb:1055:in `main': Thread(0xa543a80): deadlock 
(fatal)
    from ./rubyripper_gtk2.rb:1095

Original comment by mordbr...@gmail.com on 5 Aug 2008 at 1:20

[GoogleCodeExporter]

ArgumentErrors are the worst there are ;) Try r280 please and see if it fixes
anything.

Original comment by rubyripp...@gmail.com on 5 Aug 2008 at 2:19

[GoogleCodeExporter]

No change in the behavior.  Ripping dir ends up looking like this (I only 
ripped the
last track on the disc to test):

)$ tree
.
|-- Sykdom (2004) Intet liv
|   |-- Sykdom - Intet liv (wav).cue
|   `-- ripping.log
`-- temp
    `-- track9_1.wav

2 directories, 3 files

GUI still freezes and ruby hogs cpu.

Original comment by mordbr...@gmail.com on 5 Aug 2008 at 8:35

[GoogleCodeExporter]

Since you're the only one that's having this problem so far, I've looked once 
again
to your config file. What happens when you change your basedir to a place that 
hasn't
'special' characters in it?

Original comment by rubyripp...@gmail.com on 5 Aug 2008 at 8:41

[GoogleCodeExporter]

Tried another dir, same problem.  I can't figure out why I'm the only one with 
the
issue.  I zapped my configuration and even tried a fresh svn checkout (instead 
of
update) to no avail.

This spits out after ruby spikes the CPU usage and I click the close X in my 
window
manager:
Adding track 9 (wav) into the waitingroom..
Inside handleThreads: maxthreads = 1, threads = 0
busytracks = 9, track = 9, codec = wav
(eval):11: [BUG] Segmentation fault
ruby 1.8.7 (2008-06-20 patchlevel 22) [i486-linux]

Aborted

Original comment by mordbr...@gmail.com on 5 Aug 2008 at 9:45

[GoogleCodeExporter]

come to think of it: if there is a problem in the evaluation / comparison 
portion of
the code that could explain why the temp tracks aren't removed and the lack of
complete wav file in the album dir.

Original comment by mordbr...@gmail.com on 5 Aug 2008 at 9:55

[GoogleCodeExporter]

I suspect this one is related to issue 221. Can you please confirm the 
workaround of
setting extra encoding threads to 0 solves the Segmentation fault?

Original comment by rubyripp...@gmail.com on 6 Aug 2008 at 8:23

[GoogleCodeExporter]

Can you confirm latest svn fixes your problems?

Original comment by rubyripp...@gmail.com on 6 Aug 2008 at 10:41

[GoogleCodeExporter]

Changing extra encoding threads to 0 (from 1) seems to fix the problems.  Never
thought that setting could be a problem since I leave everything in wav (but I
understand why, now).

Original comment by mordbr...@gmail.com on 7 Aug 2008 at 4:37

[GoogleCodeExporter]

I don't think this is a solution ofcourse. I'll keep on searching for a real 
solution
while solving issue 221. Meanwhile it's not much use to keep two issues open 
for the
same thing. So this one gets marked as a duplicate.

Original comment by rubyripp...@gmail.com on 7 Aug 2008 at 7:48

• Changed state: Duplicate