rubyripper should be more verbose about ScanDiscCdparanoia.waitForDisc errors

[GoogleCodeExporter]

Right now, rubyripper does not display errors raised in 
ScanDiscCdparanoia.waitForDisc(), leading to only receiving cryptic "No disc 
found at trial N!" errors when (for example) the device file is not found to be 
both readable and writable in PermissionDrive.isReadAndWritable?

This might need a few (minor) architectural changes, as right now, errors 
appear to come from three different sources:

1. @status will be set to 'error' and @error in the ScanDiscCdparanoia object 
will be set with a [code, parameters] pair, if 
ScanDiscCdparanoia.isValidQuery(query) fails.
2. @status may be set to a localized string for "ERROR: No audio tracks found!" 
if there @audioTracks is 0 in ScanDiscCdparanoia.addExtraInfo().
3. @status may be one of a number of localized strings returned by 
PermissionDrive.check(cdrom, query)

This can probably be fixed in two steps:

1. Stick with the localized strings in @status; change 
ScanDiscCdparanoia.isValidQuery(query) to set @status with localized strings 
instead of setting @error (with this change, you will no longer even need 
@error, and you may be able to replace calls to setError and unsetError with 
"@status = [whatever]" and "@status = nil" appropriately)
2. Display the value of @status either before or after "No disc found at trial 
%s!" (probably before).  This may need finessing for the GTK build to avoid 
popups, as I'm not familiar with how @out.puts would work in that scenario.

I'll see what I can do about a patch in the next few days.

Original issue reported on code.google.com by comradec...@gmail.com on 31 Oct 2011 at 2:52

[GoogleCodeExporter]

Alternately, if you want to standardize error handling to follow the mode in 
checkConfigBeforeRipping, you'd need to change 
ScanDiscCdparanoia.addExtraInfo() and PermissionDrive.check(cdrom,query) to 
properly handle the [code, parameters] pair and format it.

Original comment by comradec...@gmail.com on 31 Oct 2011 at 3:00

[GoogleCodeExporter]

I think this problem is solved with latest commits. In a slightly related note, 
the error handling and communication to the user interface needs some attention 
indeed. The same applies for translations.

But one thing at a time ;)

Original comment by boukewou...@gmail.com on 5 Nov 2011 at 10:45

• Changed state: Fixed