GUI Freeze / Crash with extra encoding threads enabled

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Insert Any CD
2. Begin Ripping

What is the expected output? What do you see instead?

rrip_gui seems to freeze.  All the trials for the first track are reported
properly in the status screen in rrip_gui.  After that first track,
however, nothing more is reported.  The program continues on ripping all
the remaining tracks and seems to evaluate the various trials for
differences (after all trials for a track it deletes all but one) BUT it
does not encode them (the first track DOES get encoded - in this case to
vorbis).  If you let the whole CD go through cdparanoia will stop ripping
and you will have the whole CD in untouched wav files in the temp folder
but rrip_gui will just sit there, not having reported anything since the
first track and not having encoded anything but the first track, until you
kill the program.  Neither status bar ever moves from 0%.  I also made sure
that there were only basic characters in all the metadata fields in case
that might have been the issue - that didn't have any effect.

What version of rubyripper are you using? On what operating system? Are you
using the gtk2 or the commandline interface?

SVN r281, Debian Lenny, gtk2

Original issue reported on code.google.com by jbfun...@gmail.com on 5 Aug 2008 at 6:40

[GoogleCodeExporter]

A bit more info:
All the metadata for that first track is tagged correctly in the ogg file.  
Also, the
audio in that file is complete.  Additionally, the logfile in the output 
directory
looks completely normal.  The CD ejects, also as normal, after being ripped.

Original comment by jbfun...@gmail.com on 5 Aug 2008 at 6:48

[GoogleCodeExporter]

Also, the logfile was NOT deleted even though "Only keep logfile if correction 
is
needed" was checked and there was no correction needed.  After the first track 
the
gui is completely unresponsive and, if it has been moved or if you've switched
desktops, is just a white and gray blank box.

Original comment by jbfun...@gmail.com on 5 Aug 2008 at 6:54

[GoogleCodeExporter]

3 questions:

1) Are you running rubyripper with debug=true? Perhaps some message will show 
up in
the terminal.
2) Is any correction performed or is it a straight match each time?
3) Can you post your settings file? ( $HOME/.rubyripper/settings )

Original comment by rubyripp...@gmail.com on 5 Aug 2008 at 6:56

• Changed state: Accepted

[GoogleCodeExporter]

1) I have run with debug=true and the output appears normal on the terminal - 
just
the cdparanoia output and the vorbis output (for the first track).
2) It is a straight match.  The CD is in very good condition.
3)
req_matches_all=3
naming_various=%g/%a/%b/%n - %va - %t
vorbissettings=-q 7
flacsettings=--best
edit=false
freedb=true
naming_normal=%g/%a/%b/%n - %t
max_tries=8
wav=false
gain=album
req_matches_errors=4
editor=gedit
username=anonymous
verbose=true
maxThreads=1
mp3=false
normalize=replaygain
first_hit=true
cdrom=/dev/hdc
create_cue=false
site=http://freedb2.org:80/~cddb/cddb.cgi
playlist=false
other=false
no_log=true
filemanager=nautilus --no-desktop
hostname=my_secret.com
eject=true
instance=main
debug=true
naming_image=%f/%a (%y) %b/%a - %b (%y)
basedir=/home/music
othersettings=
mp3settings=-V 3
image=false
rippersettings=-Z
offset=0
vorbis=true
flac=false

Original comment by jbfun...@gmail.com on 5 Aug 2008 at 7:10

[GoogleCodeExporter]

This happened to me before.  I found that setting "Number of extra encoding 
threads"
to '0' fixed it on mine.  I'm not sure but I think on the settings file that is
"maxThreads".  Could be wrong.

Original comment by tdto...@gmail.com on 5 Aug 2008 at 9:25

[GoogleCodeExporter]

I can confirm that setting the maxThreads to 0 does allow rubyripper to function
properly.  This is successful as a workaround.  Setting maxThreads to 1 or 2 or
anything greater generates the same behavior as outlined initially.  However, I
really like the ability to encode and rip simultaneously - it's a great time 
saver...
and it DID work not so long ago when I was using .5.0 - if I downgrade back to 
.5.0
now, the freezing problem is still there, though, which makes me think that this
might have to do with some ruby update...

Original comment by jbfun...@gmail.com on 5 Aug 2008 at 11:10

[GoogleCodeExporter]

I wonder if it's related to this, kinda think it does:
http://ruby-gnome2.sourceforge.jp/hiki.cgi?tips_threads

This would imply it's not really my fault. Anyway I'll see if the workaround 
they're
offering can be implemented.

Original comment by rubyripp...@gmail.com on 5 Aug 2008 at 11:58

[GoogleCodeExporter]

This issue might be a duplicate of issue 212.

Original comment by rubyripp...@gmail.com on 6 Aug 2008 at 9:38

[GoogleCodeExporter]

Does r286 fix anything? I've locked the updating of the gui, so only one update 
can
happen at a time. The interface might feel less responsive though, see it as a 
proof
of concept. If this works, I can finetune it a little.

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

[GoogleCodeExporter]

I just checked it with r291 and 1 extra encoding thread and it still happens.

Original comment by tdto...@gmail.com on 6 Aug 2008 at 11:29

[GoogleCodeExporter]

Locked the updating of the log messages too in r292. It might help, though I'm 
not
too optimistic.

I've marked issue 212 as a duplicate.

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

• Changed title: GUI Freeze / Crash with extra encoding threads enabled

[GoogleCodeExporter]

r292 has the same issues.  I also tried r300 and it seems to introduce major 
issues
with metadata - it says it can't connect to freedb, throws this message:

Exception thrown: undefined local variable or method `name' for 
#<Metadata:0xb7a2e36c>

Then actually DOES find the metadata (and it's not finding it locally).  

When I press rip it throws this and exits:

/usr/lib/site_ruby/1.8/rr_lib.rb:108:in `dup': can't dup NilClass
     from /usr/lib/site_ruby/1.8/rr_lib.rb:108:in `clean'
     from /usr/lib/site_ruby/1.8/rr_lib.rb:167:in `get_filename'
     from /usr/lib/site_ruby/1.8/rr_lib.rb:1394:in `prepare_dirs'
     from /usr/lib/site_ruby/1.8/rr_lib.rb:1392:in `each'
     from /usr/lib/site_ruby/1.8/rr_lib.rb:1392:in `prepare_dirs'
     from /usr/lib/site_ruby/1.8/rr_lib.rb:1325:in `settings_ok'
     from /usr/bin/rrip_gui:220:in `start_rip'
     from /usr/bin/rrip_gui:88:in `create_signals'
     from /usr/bin/rrip_gui:1117:in `call'
     from /usr/bin/rrip_gui:1117:in `main'
     from /usr/bin/rrip_gui:1117

Original comment by jbfun...@gmail.com on 7 Aug 2008 at 6:41

[GoogleCodeExporter]

Please try r301..

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

[GoogleCodeExporter]

That solved the first part - ie no "Exception thrown..." - however, the program 
still
exits directly after pressing the rip button and outputs:

/usr/lib/site_ruby/1.8/rr_lib.rb:108:in `dup': can't dup NilClass
     from /usr/lib/site_ruby/1.8/rr_lib.rb:108:in `clean'
     from /usr/lib/site_ruby/1.8/rr_lib.rb:167:in `get_filename'
     from /usr/lib/site_ruby/1.8/rr_lib.rb:1393:in `prepare_dirs'
     from /usr/lib/site_ruby/1.8/rr_lib.rb:1391:in `each'
     from /usr/lib/site_ruby/1.8/rr_lib.rb:1391:in `prepare_dirs'
     from /usr/lib/site_ruby/1.8/rr_lib.rb:1324:in `settings_ok'
     from /usr/bin/rrip_gui:220:in `start_rip'
     from /usr/bin/rrip_gui:88:in `create_signals'
     from /usr/bin/rrip_gui:1117:in `call'
     from /usr/bin/rrip_gui:1117:in `main'
     from /usr/bin/rrip_gui:1117

Original comment by jbfun...@gmail.com on 7 Aug 2008 at 7:01

[GoogleCodeExporter]

Please try r302...

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

[GoogleCodeExporter]

r302 almost fixes it...  The program no longer crashes, but when it should be
encoding to vorbis it throws this:

sh: -c: line 0: unexpected EOF while looking for matching `"'
sh: -c: line 1: syntax error: unexpected end of file

That corresponds with this error message in the log:

WARNING: Encoding to vorbis exited with an error with track 1!

There ARE wav files being generated in the temp directory (though they 
disappear once
the program has started ripping the next track).

This is all with threads at 0 - threads set to 1 still has the same problem as 
above.

Original comment by jbfun...@gmail.com on 7 Aug 2008 at 9:00

[GoogleCodeExporter]

r305 should solve the problems. I was testing with a various artist disc. But 
then I
missed the bugs that occured only with normal discs.. 

I'll be gone for two weeks now, so please be patient.

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

[GoogleCodeExporter]

Thanks for all the hard work on this - it looks like, as you said, this whole 
thing
is probably a result of something in ruby itself and I really appreciate that 
you're
willing to try to fix it in the code on this end.  In the mean time it's great 
that
it's working again, even if it is without simultaneous rip and encode...  it 
doesn't
add all that much time anyway.

Original comment by jbfun...@gmail.com on 7 Aug 2008 at 9:50

[GoogleCodeExporter]

Please test if r307 fixes anything.

Original comment by rubyripp...@gmail.com on 18 Aug 2008 at 6:55

[GoogleCodeExporter]

It's still happening on mine.  This time I also had quite a few warnings when I 
built it.

Original comment by tdto...@gmail.com on 19 Aug 2008 at 6:55

[GoogleCodeExporter]

The problem with this issue is, that I can't reproduce it. I suspect it has 
something
to do with either the ruby version or its compile time options. So I'll post 
mine
(working) set-up:

ruby --version : ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
ruby configure options:  --enable-shared --enable-pthread

Can anyone that's having problems post the same?

Your ruby configure options can be found in the repository of your distribution
(probably).

Original comment by rubyripp...@gmail.com on 31 Aug 2008 at 12:17

[GoogleCodeExporter]

I am now currently on ruby 1.8.7 p 72 compiled with those options.  Before I 
was on
1.8.6 p230.  I'm pretty sure my original package was compiled with those options
since they're very common but I'm not positive.  From ruby-gnome2 0.17.0-rc1 I 
have
ruby glib2, ruby atk, ruby pango, ruby gtk, ruby gdkpixbuf2, and ruby libglade. 
 I'm
sorry to say that it's still happening though.  If we're on the same version of
ruby-gtk2 then I don't know what to tell you.

Original comment by tdto...@gmail.com on 1 Sep 2008 at 4:52

[GoogleCodeExporter]

Now the latter is not true. Can you try to downgrade to 0.16 to see if 0.17
introduces the problem?

Original comment by rubyripp...@gmail.com on 6 Sep 2008 at 9:57

[GoogleCodeExporter]

I would if I could find a good copy of the source for it.  I can't find older 
sources
at sourceforge.  I did manage to find one copy of 0.16 somewhere but I had build
errors.  I found on a Gentoo page somewhere that they had the exact same 
problems and
had released a 0.16 r3 that supposedly fixed the problem but I could not find 
the
source for that.  Just a Gentoo ebuild for it whatever that is.  I think most 
likely
I'll just have to stick with not using extra encoding threads for now until a 
newer
version of ruby-gnome2 comes out or I can find a version of 0.16 I can actually 
build.

Original comment by tdto...@gmail.com on 7 Sep 2008 at 4:40

[GoogleCodeExporter]

I can confirm that the 0.17 upgrade causes the problems. Since I have the 
problem now
myself, I'll have really good motivation to solve it ;)

Original comment by rubyripp...@gmail.com on 24 Sep 2008 at 5:03

[GoogleCodeExporter]

Thanks for looking into that!  I was beginning to wonder if it was something I 
was doing.

Original comment by tdto...@gmail.com on 25 Sep 2008 at 3:51

[GoogleCodeExporter]

Can anyone explain what the 'Number of extra encoding threads' option does?
Setting maxThreads=0 made my Rubyripper work again, but I haven't had any luck
finding an explanation of 'maxthreads'...

Thanks in advance!

Original comment by and...@gmail.com on 12 Oct 2008 at 12:55

[GoogleCodeExporter]

Number of extra encoding threads resulted in multiple processes running parralel
instead of waiting on each other. This is giving a nice speedup on multicore 
systems,
wich are standard nowadays.

However, in version 0.5.4 I've disabled threading altogether. There was no easy 
fix.
The problems were introduced with the release of 0.17 bindings of gtk, not by 
any
changes of rubyripper. Since then it's not possible to create a new process in a
thread that is different than the main gtk thread. It resulted in a freezing 
gui and
an infinite loop in ruby itself. That is, if I understood it correctly.

I am not sure that creating the process in the main gtk thread will solve the
problems. But it changes the whole setup of rubyripper. Now the handling of the
ripping and encoding takes place in a separate class. This makes it possible to 
be
independant of the frontend.

To enable the thread creation in the main gtk thread would require a rewrite of 
this.
I am not sure this is a good idea. Perhaps a callback that passes the command 
is an
option. But how can you tell it's finished? This is no elegant solution anyhow.

I'll keep this issue open, hoping that I'll have the time and the brains to 
solve
this in a next release.

Original comment by rubyripp...@gmail.com on 1 Nov 2008 at 11:19

[GoogleCodeExporter]

This is sad... i dont even use the GUI, which means this bug would not affect 
me...
Still i cant use threading anymore.. This slows down ripping a lot!

Original comment by rasi1...@googlemail.com on 1 Mar 2009 at 1:17

[GoogleCodeExporter]

New release, new changes. Trying to fix threaded encoding.

Having fixed some other gui related problems I felt in good
shape to fix this longstanding problem. But after enabling
the extra threads I could not reproduce the problem anymore
like I did before.

This made me get some hope that recent ruby-gtk2 implementations
got fixed somehow. One should never be too enthousiastic about
this kind of things. Who knows where rubyripper will break else?
This needs some testing on more systems.

Anyway, I am much in favour for this feature. And am willing to
do some heavy research on it this summer if needed.

Please download latest git and give it a run to see if you can reproduce the 
original
problems. If you do, please post your ruby-gtk2 version that is installed on 
your system.

Original comment by rubyripp...@gmail.com on 6 Jul 2009 at 9:10

[GoogleCodeExporter]

Can anyone else report success with latest git?

Original comment by rubyripp...@gmail.com on 8 Jul 2009 at 5:10

[GoogleCodeExporter]

I am having success with the latest git, and it is definitely using multiple 
threads
because as tracks are being ripped others are being checksumed and converted.

I don't know whether this matters but I changed maxThreads from 0 to 2 before
ripping, I assume others should be doing similar when using the git.

Using latest git, Arch Linux and the gtk2 frontend.

Original comment by fergof...@gmail.com on 9 Jul 2009 at 12:09

[GoogleCodeExporter]

This indeed matters :) You can set as many extra threads as you want to. But it 
only
makes sense to set as many as your CPU has cores. The gui has the setting also
available in the codec tab.

Since I use Arch Linux myself it would be nice if anyone else with a different 
distro
can give some response.

Original comment by rubyripp...@gmail.com on 9 Jul 2009 at 6:40

[GoogleCodeExporter]

No complaints mean that this is fixed. If you still have a configuration with
problems, please report which version of ruby-gtk2 you're using.

Original comment by rubyripp...@gmail.com on 11 Jul 2009 at 9:24

• Changed state: Fixed