Excessive time between ripping tracks

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  Rip CD
2.  rr finishes the 2nd trial of a track... then 10-15 minutes later goes
on to the next track.

Please use labels and text to provide additional information.
Drive and CPU are inactive... not sure what is the cause of the delay.

Happening with rr git Mon Aug 24 20:32:07 2009 +0200 
12ed4b76c8f1a98043b063b5cd6b33f9b09260d5

Original issue reported on code.google.com by mordbr...@gmail.com on 27 Aug 2009 at 3:02

[GoogleCodeExporter]

Seems it's not a rr problem.  Now to figure out what package is b0rk3d.

Original comment by mordbr...@gmail.com on 28 Aug 2009 at 1:16

[GoogleCodeExporter]

Maybe not a ruby problem either?

$ irb1.8 
irb(main):001:0>  require 'benchmark'; require 'digest/md5'; Benchmark.bm {|bm|
bm.report {1000000.times {Digest::MD5.hexdigest('abc123')}}}
      user     system      total        real
  5.660000   0.040000   5.700000 (  6.128815)
=> true

Original comment by mordbr...@gmail.com on 28 Aug 2009 at 8:23

[GoogleCodeExporter]

Whatever is going on relates to the size of the wav file, so something is 
definitely
slowed down.  Still can't figure out what though. 

Original comment by mordbr...@gmail.com on 11 Sep 2009 at 11:05

[GoogleCodeExporter]

Please give me some information about your:
* ruby version
* ruby-gtk version
* cpu (single / dual core)

Original comment by rubyripp...@gmail.com on 18 Sep 2009 at 6:55

[GoogleCodeExporter]

$ ruby -v
ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux]

$ dpkg -l |grep -i ruby |grep -i gtk
ii  libgtk2-ruby                         0.19.1-1                     GTK+ 
bindings
for the Ruby language
ii  libgtk2-ruby1.8                      0.19.1-1                     GTK+ 
bindings
for the Ruby language

Single core CPU

Original comment by mordbr...@gmail.com on 18 Sep 2009 at 7:01

[GoogleCodeExporter]

I guess that excludes the option that gtk binding is outdated. Can you please 
verify
with "top" or any other system monitor what is going on with the cpu percentage 
of
rubyripper?

Original comment by rubyripp...@gmail.com on 18 Sep 2009 at 7:03

[GoogleCodeExporter]

CPU percentage is low while this happens.  I have gkrellm graphing my cpu usage 
and I
usually notice if it spikes.  I can positively say CPU is not the bottleneck 
when
this is going on.  In fact, if my memory is right, it should use a lot of CPU 
and do
the comparison and/or md5 quickly, then move on.  This no longer happens.

Original comment by mordbr...@gmail.com on 18 Sep 2009 at 7:14

[GoogleCodeExporter]

I suspect this is a threading problem of some kind. It doesn't really make sense
though why I am not experiencing the same thing then. It actually acts pretty
fluently with latest ruby. This is on a AMD-3800-dual core.

Original comment by rubyripp...@gmail.com on 18 Sep 2009 at 8:06

[GoogleCodeExporter]

When exactly does it hang? What is the last string message before the hang?

Original comment by rubyripp...@gmail.com on 18 Sep 2009 at 8:08

[GoogleCodeExporter]

Expected size matches exactly

Original comment by mordbr...@gmail.com on 18 Sep 2009 at 8:19

[GoogleCodeExporter]

woops, itchy trigger finger ;)

It slows after that matches exactly message (comparing the files (top says ruby 
is
using 1-2% of cpu)).  Then it starts ripping the next track while it's still 
writing
the final wav file (very very slowly).

Original comment by mordbr...@gmail.com on 18 Sep 2009 at 8:25

[GoogleCodeExporter]

Let me get this right: you are saying that the message: "Every chunk matched %s
times", is the last one before the slowdown?

I am wondering, how can you tell it's still writing the final wav file?

Original comment by rubyripp...@gmail.com on 19 Sep 2009 at 1:42

[GoogleCodeExporter]

No, slowdown starts after "Expected size matches exactly" when the comparison 
begins.

I can tell it's still writing the wav, because if I go to the output dir and do 
ls -l
a few times the last file keeps increasing in size (slowly).

Original comment by mordbr...@gmail.com on 19 Sep 2009 at 2:15

[GoogleCodeExporter]

It seems to me you're referring to the newly encoded file instead of the source 
wav
file. In case you're outputting to wav this isn't logical as well, because it's 
a
standard copy action which shouldn't take long enough to monitor the growing 
filesize.

Looking at the code I see the following. If above message is shown, the wav 
file is
finished. After that only the md5 checksum is calculated. When the md5 checksum 
is
finished, the file will be added as ready for the Encoding class. Only from that
point can it start with the encoding.

An easy way to find out if it is really the md5 part that is giving problems, 
please
comment out line 1691: "getDigest(track) # Get a MD5-digest for the logfile". 
You can
do so by putting a '#' before the line.

You also might wanna try if ripping with 0 extra threads helps anything.

Please report your results.

Original comment by rubyripp...@gmail.com on 19 Sep 2009 at 2:34

[GoogleCodeExporter]

Yes, the newly encoded file, which in my case is a wav.  The baffling part is, 
like
you say, it's doing a copy of the wav but it's taking minutes unless it's a very
short song (~30 seconds).

commented out line #1691 to no benefit.  Also I had 0 threads before and it 
displayed
the same behavior.

An example of the final "encoded" wav growing in size:
$ date; ls -l *.wav
Sat Sep 19 15:31:36 PDT 2009
-rw-r--r-- 1 jebediah jebediah 21016576 2009-09-19 15:31 01 - Track 1.wav
[jebediah@manger]-(/Sjø/wav/Unknown (0) Unknown)$ date; ls -l *.wav
Sat Sep 19 15:31:38 PDT 2009
-rw-r--r-- 1 jebediah jebediah 21254144 2009-09-19 15:31 01 - Track 1.wav
[jebediah@manger]-(/Sjø/wav/Unknown (0) Unknown)$ date; ls -l *.wav
Sat Sep 19 15:31:40 PDT 2009
-rw-r--r-- 1 jebediah jebediah 21819392 2009-09-19 15:31 01 - Track 1.wav
[jebediah@manger]-(/Sjø/wav/Unknown (0) Unknown)$ date; ls -l *.wav
Sat Sep 19 15:31:42 PDT 2009
-rw-r--r-- 1 jebediah jebediah 22114304 2009-09-19 15:31 01 - Track 1.wav

Original comment by mordbr...@gmail.com on 19 Sep 2009 at 10:29

[GoogleCodeExporter]

After ripping a disc it does seem to go a little faster with that line 
commented out,
but it's still going slow.  Probably because the md5sum code is called after 
each rip.

Original comment by mordbr...@gmail.com on 20 Sep 2009 at 3:41

[GoogleCodeExporter]

As commenting out the line does not make a significant difference, the md5 
checksum
is NOT to blame.

Do you have the same problems if you choose another codec? Or when you set 
encoding
threads to 0?

Original comment by rubyripp...@gmail.com on 20 Sep 2009 at 7:59

[GoogleCodeExporter]

Encoding threads set to 0 does not resolve this.  With another codec it still 
takes a
long amount of time after the second rip is complete (and comparison begins). 
Terminal shows:
Expected size matches exactly
while gui shows:
Analyzing files for mismatching chunks
then after a good length of time gui displays:
Every chunk matched 2 times :)
which leads to another lengthy delay until the encoded file appears in the 
output
directory.

trying with another codec didn't fix it either, although there is a little 
speedup
because an ogg file is much smaller than a wav.

Original comment by mordbr...@gmail.com on 20 Sep 2009 at 10:19

[GoogleCodeExporter]

Does this seem right at all?  busytracks = 23 raises my suspicions.

(== PROGRESS == [                       >      | 056360 00 ] == :-) . ==)  
busytracks = 23, track = 2, codec = wav

Original comment by mordbr...@gmail.com on 27 Sep 2009 at 3:16

[GoogleCodeExporter]

I've seen this problem here too.  After some testing it looks like a large 
fraction
of the time is being spent in this code in analyzeFiles:

  if !@errors.key?(index) && files[0].read(2352) != files[time + 1].read(2352)

I took out the core of this loop and ran it as a separate program on two test 
wav
files and it compared them in less than a second.

Further, this code is running within rubyripper, there is essentially no cpu 
load
(via top/atop) and no disk activity (via iostat or iotop).  So I would also 
suspect a
threading/blocking issue.

This was tested with Debian ruby 1.8.7.174-2 and rubyripper 0.5.7.

Original comment by r...@defaultvalue.org on 21 Nov 2009 at 7:09

[GoogleCodeExporter]

I recently began having this same problem. It rips the two trial wavs very 
quickly, 
then begins the "analyzing files for mismatching chunks" phase which takes 
forever.

I'm not sure at what point exactly did this behavior begin, I think everything 
was 
fine just a couple of weeks ago. Maybe I'll try downgrading something and see 
if it 
helps. System is Gentoo with Rubyripper 0.5.7.

Original comment by finnpant...@yahoo.com on 30 Dec 2009 at 2:10

[GoogleCodeExporter]

I am also a Gentoo user. The same problem happened to me when I upgrade Ruby.
(ruby-1.8.7_p174-r1 => ruby-1.8.7_p249)
And to downgrade Ruby, the problem did not occur.
(ruby-1.8.7_p174-r1.ebuild has already been removed, so I downgraded to 
ruby-1.8.6_p388)

Original comment by ichelm6...@gmail.com on 14 Jan 2010 at 7:49

[GoogleCodeExporter]

On Debian downgrading to ruby1.8/stable and libruby1.8/stable did not solve the
problem.  Nor did testing or unstable.  The relevant Debian bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539987 gives the ever so 
helpful
advice to wait for ruby1.9... but that is missing the gtk2 depends and stuff in 
the
Debian repositories.  Fun times!

This is looking like not a bug with rr, but I can't verify and I'm sure others 
will
find the info here useful (and maybe save duplicate bug reports).

Original comment by Fjellf...@gmail.com on 15 Jan 2010 at 2:31

[GoogleCodeExporter]

ahoy all.

  i can verify that this problem occurs on same Gentoo setup as comment #22.  i can
also report that this problem does not occur on same hardware running Trisquel 
3.0,
running rubyripper 0.5.7, though an older version of ruby.

peace.

Original comment by in0g...@in-giro.org on 4 Feb 2010 at 7:52

[GoogleCodeExporter]

I upgraded to the version of Debian's ruby that claims to fix the bug that 
comment #23 
links to (fixed in version 1.8.7.249-3), but I still get this same problem.

Original comment by mark.j.n...@gmail.com on 16 Apr 2010 at 9:38

[GoogleCodeExporter]

same problem..

With ruby 1.9.1p378 everything work fast and fine.
So, this is a Ruby1.8 bug, not rr.

I'm not sure..maybe related:
https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/307462

bye

Original comment by bettinso...@gmail.com on 21 Apr 2010 at 4:08

[GoogleCodeExporter]

Issue 375 has been merged into this issue.

Original comment by boukewou...@gmail.com on 24 Apr 2010 at 2:27

[GoogleCodeExporter]

Issue 304 has been merged into this issue.

Original comment by boukewou...@gmail.com on 24 Apr 2010 at 6:17

[GoogleCodeExporter]

I can reproduce this with Ruby 1.8 on Debian Squeeze.

While there can be not doubt that this is due to the choice of distributions to
enable pthread support (resulting in an excessive number of interrupts as can 
be seen
using strace) many distributions are affected.

Hence, I am asking if there is any known solution that does not require an
alternative version of Ruby?

Original comment by fred...@witherden.org on 6 May 2010 at 8:34

[GoogleCodeExporter]

Can anyone please check if latest git fixes your problems? I've improved the 
mechanism 
for handling encoding threads. It may be related I think.

Original comment by boukewou...@gmail.com on 17 May 2010 at 9:52

[GoogleCodeExporter]

The latest rubyripper pulled from Git still has this issue with ruby 1.8.7.249 &
ruby-gtk 0.19.3. OS is Ubuntu Linux 10.04, with kernel 2.6.34-rc6.

On a track rip that took 40 seconds for each of two trials, it hung on 
"Analyzing
files for mismatching chunks" for 4 minutes 35 seconds
and then on "Every chunk matched 2 times :)" for 2 minutes 20 seconds.

Original comment by richardw...@gmail.com on 17 May 2010 at 11:09

[GoogleCodeExporter]

It isn't too difficult to build Ruby 1.9.1 plus the GTK2 bindings from source 
on 
Ubuntu 10.04 (and I would assume Debian although I haven't tested that).

N.B. The following instructions work well enough for me to get RubyRipper 
working. 
This is the only Ruby program I use so I wouldn't assume this is a complete 
stack.

## Ruby

$ sudo aptitude install build-essential libc-dev libssl-dev libreadline-dev

download and extract latest stable release from http://www.ruby-
lang.org/en/downloads/

$ cd ruby-1.9.1-p376/
$ ./configure --prefix=/usr/local
$ make
$ make test
$ sudo make install

$ which ruby
/usr/local/bin/ruby
$ ruby -v
ruby 1.9.1p376 (2009-12-07 revision 26041) [x86_64-linux]

## GTK2 Bindings

$ sudo aptitude install libgtk2.0-dev

download and extract latest ruby-gtk2 release from 
http://sourceforge.net/projects/ruby-gnome2/files/

$ cd ruby-gtk2-0.19.4/
$ ruby extconf.rb
$ make
$ sudo make install

Hope this workaround helps until Ruby 1.8 is fixed and/or the distros include a 
full Ruby 1.9 stack.

Original comment by tin...@gmail.com on 22 May 2010 at 1:04

[GoogleCodeExporter]

I just checked in a commit which may solve this problem. It prevents the 
creation of 
threads within the SecureRip class. I thought this wouldn't be needed since the 
gui is 
already running in a different thread. Since this issue seems to be related to 
the way 
threads are compiled in, it may help. But I thought so before.

Perhaps someone can verify with latest git code (see tab Source).

Original comment by boukewou...@gmail.com on 22 May 2010 at 7:56

[GoogleCodeExporter]

The problem persist.

Rubyripper version 0.6.0rc1.
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]
Intel Core 2 T5500 1.66GHz

Ripping only one track (first track). attached rubyripper settings.

From a terminal:

Ripping track 1
Expected filesize for track 1       is 41668076 bytes.
Free disk space is 16038728 MB
Minutes ripping is 0.00043985.
cdparanoia [.0]-[.17715] -d /dev/cdrom -O 667 
"/home/simo/Musica/temp_sr0/track1_1.wav"
cdparanoia III release 10.2 (September 11, 2008)

Ripping from sector       0 (track  0 [0:00.00])
      to sector   17715 (track  1 [3:56.14])

outputting to /home/simo/Musica/temp_sr0/track1_1.wav

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

Done.

Minutes ripping is 0.995709266666667.
cdparanoia [.0]-[.17715] -d /dev/cdrom -O 667 
"/home/simo/Musica/temp_sr0/track1_2.wav"
cdparanoia III release 10.2 (September 11, 2008)

Ripping from sector       0 (track  0 [0:00.00])
      to sector   17715 (track  1 [3:56.14])

outputting to /home/simo/Musica/temp_sr0/track1_2.wav

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

Done.

-------------after that..nothing for about 5 minutes.---------------

Top say:
 PID   USER      PR  NI  VIRT   RES   SHR  S  %CPU  %MEM    TIME+    COMMAND  
 3739  simo      20   0  261m   41m   13m  S    2    4.2    0:17.18   ruby

Original comment by bettinso...@gmail.com on 25 May 2010 at 6:04

Attachments:

• settings

[GoogleCodeExporter]

Maybe I should remove the line if $RUBY_VERSION < 1.9 ; sleep(100) ; end :D

But serious, there doesn't seem to be any logical explanation why the behaviour 
for 
ruby-1.8 differs so much from ruby-1.9. Let's hope the distros will be updating 
to 
ruby-1.9 soon. It has been there for about 1,5 year after all. A new rubyripper 
release might just help this process.

Original comment by boukewou...@gmail.com on 26 May 2010 at 6:36

[GoogleCodeExporter]

> why the behaviour for 
ruby-1.8 differs so much from ruby-1.9.

It appears it's only the p249 version of 1.8 - earlier versions work

On ubuntu 10.04 there are several options - none great. As described above in 
post 32
works, or you can use the repo 1.9.1 to build the ruby-gtk2 off of. (I used the 
repo
1.9.1 here (p378
either way you may break ruby if used elsewhere

You could also revert libruby1.8 to the p174 ver, though that may involve at 
least 16
packages - hardly worth it (the ubuntu packaging of ruby is quite twisted to 
say the
least

The best option may be to just use the gui for setting options, parameters, 
ect. and
then rip from the cli either interactively or with an -a or -d depending on rr 
version

Original comment by mc3...@optonline.net on 27 May 2010 at 3:42

[GoogleCodeExporter]

I am also going to say I am having this problem, as is a friend of mine. Both 
of us 
had no issues with 9.10, but are having issues with 10.04. I used the fix from 
post 
32 but now RR won't load. I launched it from a terminal window with this 
command 
'rrip_gui' and got this error:

/usr/bin/rrip_gui:594: syntax error, unexpected ':'
        if @cd.md.varArtists.empty? : @varCheckbox.active = false end
                                     ^
/usr/bin/rrip_gui:659: syntax error, unexpected keyword_do_block, expecting 
keyword_end
            @cd.audiotracks.times do |index|
                                    ^
/usr/bin/rrip_gui:668: syntax error, unexpected keyword_end, expecting $end

Any ideas?

Original comment by david.j....@gmail.com on 27 May 2010 at 9:30

[GoogleCodeExporter]

This is one of the many ruby-1.9 errors that you will typically see with the 
0.5.7 
version. The syntax has changed so the colon is no longer allowed after an if 
statement, it must be a semi-collon now. It's the very reason a new release is 
wanted 
most desperately ;) In about two weeks we should be there.

Original comment by boukewou...@gmail.com on 27 May 2010 at 9:40

[GoogleCodeExporter]

Is there an easy way to use the previous version of Ruby so RR will work?

Original comment by david.j....@gmail.com on 29 May 2010 at 6:23

[GoogleCodeExporter]

Still slow as of Wed Jun 9 19:26:08 2010 +0200 but patience will be the cure.

Original comment by mordbr...@gmail.com on 13 Jun 2010 at 2:04

[GoogleCodeExporter]

Same here using Ubuntu 10.04, Rubyripper 0.6 and ruby 1.8. It takes about 20 
seconds to rip each wav and then "Analyzing files for mismatching chunks" takes 
forever...

Original comment by rogeri...@gmail.com on 8 Aug 2010 at 9:51

[GoogleCodeExporter]

GUI is a pain. Takes forever to do anything, and the laptop was shutting down 
before the first track had finished being analyzed. Works fine in CLI mode 
however. Blasts through the CD. 

LinuxMint 9
Intel Core 2 
2G ram

Original comment by grcro...@gmail.com on 23 Aug 2010 at 10:11

[GoogleCodeExporter]

Issue 439 has been merged into this issue.

Original comment by boukewou...@gmail.com on 29 Aug 2010 at 9:49

[GoogleCodeExporter]

Issue 436 has been merged into this issue.

Original comment by boukewou...@gmail.com on 29 Aug 2010 at 9:49

[GoogleCodeExporter]

Now with Maverick beta,Rubyripper 0.6.0 and
ruby 1.8.7 (2010-06-23 patchlevel 299) [x86_64-linux]

rr still slow :(

Original comment by bettinso...@gmail.com on 26 Sep 2010 at 2:43

[GoogleCodeExporter]

notice that this only happen with gui, not cli.
bye

Original comment by bettinso...@gmail.com on 26 Sep 2010 at 2:51

[GoogleCodeExporter]

Debian has been particularly snailed paced with this, so I went through the 
instructions in http://code.google.com/p/rubyripper/issues/detail?id=348#c32 
with success (after a few silly mistakes).  Not only is the comparison speed 
back to normal, but many other bugs have disappeared as well.

Original comment by mordbr...@gmail.com on 27 Sep 2010 at 1:46

[GoogleCodeExporter]

Ok, here is a way for those who don't want to touch the entire system. Simply 
use a local copy of ruby. Open a CLI and follow these steps:

$ sudo apt-get install curl bison build-essential zlib1g-dev libssl-dev 
libreadline5-dev libxml2-dev git-core
$ bash < <(curl http://rvm.beginrescueend.com/releases/rvm-install-head)

Edit your local .bashrc and put in this as your very last line:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"  # This loads 
RVM into a shell session.

Close and reopen the CLI then

$ rvm install ruby-1.9.1
$ rvm --default ruby-1.9.1
$ gem install gettext
$ gem install gtk2

After these steps you can start rrip_gui from cli and it uses the fresh install 
of ruby and is as fast as it should be.

Sources: http://rvm.beginrescueend.com/rvm/install/
         http://tuntis.net/posts/installing-ruby-191-on-ubuntu-910-with-rvm/

Original comment by i...@baehr-koenigsbrunn.de on 27 Sep 2010 at 7:54

[GoogleCodeExporter]

In my growing despair I tried the method described in the previous comment. Now 
ruby -v shows ruby 1.9.1p378, as expected, rrip_cli works, but rrip_gui doesn't:

The ruby-gtk2 library could not be found. Is it installed?

I've got the rupyripper-6.0 package from debian-multimedia.org installed in 
Ubuntu Maverick. When I try to configure rupyripper from sourcce, I get this 
error:

ruby-gtk2 is not found. The graphical frontend won't work!

There were no errors when I did gem install gtk2. What am I doing wrong?

Original comment by thuerrsc...@gmail.com on 1 Oct 2010 at 2:30

[GoogleCodeExporter]

Could not get the solution in 48 to work.

Needed the following as well to get the gtk2 binding to work (the gem install 
gtk2 was not enough):

wget http://downloads.sourceforge.net/ruby-gnome2/ruby-gnome2-all-0.19.4.tar.gz
tar zxf ruby-gnome2-all-0.19.4.tar.gz
cd ruby-gnome2-all-0.19.4/
ruby extconf.rb --ruby=`which ruby`
make
make install

Original comment by kimti...@gmail.com on 2 Oct 2010 at 9:41