1) Please describe the steps to reproduce the situation:
a. Start an image rip on a scratched disk with a cdrom drive that has an offset
b. Some errors will be detected
c. If cdparanoia stops mid-rip before the errors can be fixed (e.g. computer
goes to sleep and spins down cdrom drive) rubyripper will crash in
correctErrorPos()
2) What is the expected output? What do you see instead?
I would expect it to either ignore that trial and start it again or compare
what was ripped so far and fix any errors it can from the partial trial.
Instead, I get a backtrace and have to start ripping all over again.
3) What version of rubyripper are you using? On what operating system? The
gtk2 of commandline interface?
I am using a recent version from the git repository. I am using the
command-line interface because of issue 348.
4) Is this not already fixed with the latest & greatest code? See for
instructions the Source tab above.
It is not fixed in the version I received from git about a week ago.
5) Does the problem happen with all discs? If not, please attach
the output of cdparanoia -Q with a disc that gives trouble.
It happens with discs where it detects errors and needs to fix them with
multiple trials.
6) Please explain why this change is important for you. Also, how many
users would benefit from this change?
It is important because I am using rubyripper for the purpose of fixing errors.
Some discs can take a long time to rip because of scratches, and if my
computer goes to sleep during this time, I have to start over. I have a disc
that I have spent many hours trying to rip, but it keeps getting interrupted
after a few hours.
I do not know how many other people have had this problem.
Please provide any additional information below. The more usefull
information provided, the sooner the issue will be fixed.
There seems to be two places where this could be fixed.
The first is in testFileSize(). Here it will try to repeat a trial if the file
size is too small, but it will ignore it if the cdrom drive has an offset and
it is either an image rip or a rip of the last track. I do not know why it
needs to ignore this, but it may be a good idea to have a threshold of how much
smaller it can be and still be considered OK.
The second place is in correctErrorPos(). Here it seems to be reading beyond
the end of the file, and then doing @errors[start_chunk].sort! which compares
to a nil value. If it could be modified to only detect errors in the partial
trial, it could still fix errors that occurred in that part of the file.
I do not know ruby very well, so I have not attempted to create a patch yet.
Here is the error and backtrace I am getting:
scsi_read error: sector=238362 length=1 retry=0
Sense key: 2 ASC: 4 ASCQ: 1
Transport error: Device not ready
System error: No medium found
scsi_read error: sector=238363 length=27 retry=0
Sense key: 2 ASC: 4 ASCQ: 1
Transport error: Device not ready
System error: No medium found
paranoia_read: CDROM drive unavailable, bailing.
(7144 seconds)
The ripped file misses 109120.741496599 sectors.
This is known behaviour for some drives when using an offset.
Notice that each sector is 1/75 second.
rr_lib.rb:2012:in `sort!': comparison of String with nil failed (ArgumentError)
from rr_lib.rb:2012:in `correctErrorPos'
from rr_lib.rb:2006:in `each'
from rr_lib.rb:2006:in `correctErrorPos'
from rr_lib.rb:1879:in `main'
from rr_lib.rb:1824:in `ripTrack'
from rr_lib.rb:1796:in `ripTracks'
from rr_lib.rb:1792:in `each'
from rr_lib.rb:1792:in `ripTracks'
from rr_lib.rb:1786:in `initialize'
from rr_lib.rb:2479:in `new'
from rr_lib.rb:2479:in `startRip'
from rubyripper_cli.rb:428:in `dir_exists'
from rubyripper_cli.rb:447:in `update'
from rubyripper_cli.rb:414:in `prepareRip'
from rubyripper_cli.rb:331:in `showFreedbOptions'
from rubyripper_cli.rb:305:in `showFreedb'
from rubyripper_cli.rb:265:in `handleFreedb'
from rubyripper_cli.rb:244:in `get_cd_info'
from rubyripper_cli.rb:47:in `initialize'
from rubyripper_cli.rb:486:in `new'
from rubyripper_cli.rb:486
Original issue reported on code.google.com by kg6...@gmail.com on 10 Mar 2011 at 3:20
Original issue reported on code.google.com by
kg6...@gmail.comon 10 Mar 2011 at 3:20