gco / rubyripper

Automatically exported from code.google.com/p/rubyripper
0 stars 0 forks source link

rubyripper hangs forever on one CD #543

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
When I want to rip a specific CD (it's called "Musikgeschichte in 
Klangbeispielen"), and click "Rip CD now", rubyripper seems to hang forever. 
Only a kill -9 can end it.

I'm using current git code, linux, gtk2-interface. I can see in ps that cdrdao 
is running when it hangs. Running the same cdrdao-command manually works, but 
reports some errors on the CD.

Any ideas how to debug this further? (and also - is there any kind of support 
forum, mailing list or chat for rubyripper? It seems to me the bugtracker is 
currently the only way to look for help at all, which is sometimes not really 
the place where things should be)

Original issue reported on code.google.com by hanno@hboeck.de on 12 Nov 2012 at 1:07

GoogleCodeExporter commented 9 years ago
If you have the debug option in preferences set to true, and start the 
application from a terminal, you might see the exact command that is giving 
trouble.

Original comment by boukewou...@gmail.com on 28 Nov 2012 at 6:44

GoogleCodeExporter commented 9 years ago
Debug output is:
DEBUG: cdparanoia -d /dev/cdrom -vQ
DEBUG: discid or cd-discid isn't found on your system!
DEBUG: Using fallback...
DEBUG: cd-info -C /dev/cdrom -A --no-cddb
DEBUG: cdrdao read-toc --device /dev/cdrom "/tmp/cdrom.toc"
DEBUG: trackselection = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 
17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27]

However, I can manually run the "cdrdao read-toc ..." command and it doesn't 
hang.  It outputs various warnings about CRC errors on that CD, but that 
shouldn't cause rubyripper to hang comletely.

Original comment by hanno@hboeck.de on 2 Dec 2012 at 10:49

GoogleCodeExporter commented 9 years ago
I added some extra debug info for executing commands:
http://code.google.com/p/rubyripper/source/detail?r=f1779202e7c036747e8b7a683623
91dc87dd83fd

Can you please retry with latest git?

Original comment by boukewou...@gmail.com on 2 Dec 2012 at 8:53

GoogleCodeExporter commented 9 years ago
Latest git doesn't seem to change anything in the output:

DEBUG: cdparanoia -d /dev/cdrom -vQ
DEBUG: cd-discid /dev/cdrom
DEBUG: cdrdao read-toc --device /dev/cdrom "/tmp/cdrom.toc"
DEBUG: trackselection = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 
17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27]

(only difference is that I installed cd-discid in the meantime)

Original comment by hanno@hboeck.de on 3 Dec 2012 at 12:50

GoogleCodeExporter commented 9 years ago
This still hurts me, as I can't rip a large number of my old CDs.
It always hangs at the cdrdao command which I can run manually. I'll attach two 
outputs + tocs of cdrdao manual runs, one of a working cd and one of a cd that 
fails. Hope that helps. Both CDs produce CRC errors.

Original comment by hanno@hboeck.de on 25 Dec 2012 at 3:12

Attachments:

GoogleCodeExporter commented 9 years ago
Okay, after further debugging, I'm almost certain I found out what the problem 
is: rubyripper seems to have trouble if there are dots in the directory name.

Starting with RUBYOPT="-w -d -W2" gave me this interesting insight:
Exception `Errno::ENOENT' at 
/software/rubyripper/lib/rubyripper/system/fileAndDir.rb:106 - No such file or 
directory - /home/hanno/opus/Scooter (1995) ...and the Beat Goes On!/Scooter - 
and the Beat Goes On! (opus).m3u

And for another one:
Exception `Errno::ENOENT' at 
/software/rubyripper/lib/rubyripper/system/fileAndDir.rb:106 - No such file or 
directory - /home/hanno/opus/Slime (1989) Live Pankehallen 21.1.1984/Slime - 
Live Pankehallen 21.1.1984 (opus).m3u

When I change the album name and remove the dots, I can rip the CD. The CD I 
reported originally has a dot in the artist name (Dr. Stefan Schaub), I cannot 
test as I don't have it here right now.

Original comment by hanno@hboeck.de on 27 Dec 2012 at 4:08

GoogleCodeExporter commented 9 years ago
I think I nailed it down with commit, though it had nothing to do with dots:
http://code.google.com/p/rubyripper/source/detail?r=5f1eadcc687c0fbb126b5c1a0997
f4ac64346af0

Can you please retry?

Original comment by boukewou...@gmail.com on 2 Jan 2013 at 7:25

GoogleCodeExporter commented 9 years ago
No, still an issue with current git. Seems I'm unable to change the status back 
to non-fixed.

Original comment by hanno@hboeck.de on 4 Jan 2013 at 9:45

GoogleCodeExporter commented 9 years ago
I think I've tracked down the issue. It is this line:
dir = File.dirname(dir) unless File.extname(dir).empty?
in the file fileAndDir.rb, function createDir. What this does is that it checks 
if a filename has an extension and then treats it as a file (and doesn't create 
a directory), if there's no extension it thinks it's the directory itself. 
However, this doesn't work as soon as the directory has a dot in it, because 
then it also is assumed it's a file.

Original comment by hanno@hboeck.de on 4 Jan 2013 at 10:03

GoogleCodeExporter commented 9 years ago
I've created a patch to fix it. Seems to me that there's only one place where 
createDir is really needed to strip a filename (for the logfile). What I did is 
stripping the filename there before the call of createDir and thus remove the 
filename-stripping from the createDir-function.
Tested with two CDs, one with dots and one without, seems to cause no problems 
but as always: please review.

Original comment by hanno@hboeck.de on 5 Jan 2013 at 9:53

Attachments:

GoogleCodeExporter commented 9 years ago
Seems there was indeed a problem. The directory was identified as a file since 
it had an extension (detected based on the dot). I changed the suggested idea 
slightly for better readability.

When the directory for a file has to be created the function now is: 
createDirForFile(file). For creating a dir the function still is createDir(dir).

See also commit:
http://code.google.com/p/rubyripper/source/detail?r=ad93a741c5ef0244aa3408148d81
7cc329d04f5a

Original comment by boukewou...@gmail.com on 5 Jan 2013 at 9:46