stalls on last track with -Z on cdparanoia

[GoogleCodeExporter]

What steps will reproduce the problem?
1. use -Z with cdparanoia to rip disc
2.
3.

What is the expected output? What do you see instead?
cdparanoia stalls on the last track

What version of the product are you using? On what operating system?
svn 13 on Debian

Please provide any additional information below.
This appears to be a cdparanoia issue; however I've not run into it while
useing cdparanoia.  I'll look into it further and see where exactly the
problem is occuring.

Original issue reported on code.google.com by mordbr...@gmail.com on 9 Nov 2006 at 11:07

[GoogleCodeExporter]

So far this happens whenever I use -Z with ccdparanoia and rr.  It happens only 
on
the last track, even if only ripping last track on every disc I've tried.  When 
I do
cdparanoia -Z -B -- "6" (where 6 is the last track) all works fine.

Original comment by mordbr...@gmail.com on 11 Nov 2006 at 4:38

[GoogleCodeExporter]

I can't figure out the logic of why this behaviour could happen. I can't think 
of a 
reason why Rubyripper is to blame. The last track doesn't get a special 
treatment, 
it's the same command as the rest.

Can you please test the '-Z' setting on the last track with rippers like grip 
too?

Original comment by rubyripp...@gmail.com on 11 Nov 2006 at 3:46

[GoogleCodeExporter]

Does it only happen on the last track that's on the cd? Say, you select only 
the 
first two tracks of a CD (with more than 2 tracks) at the start, does the 
problem 
occur then too?

Original comment by rubyripp...@gmail.com on 11 Nov 2006 at 7:24

[GoogleCodeExporter]

No, if I select the first two tracks only then it works fine.  It only happens 
on the
last track of the disc.  I think the problem is more with cdparanoia, but 
perhaps the
command you send cdparanoia could be altered to avoid it.  I'll install grip 
and test.

Original comment by mordbr...@gmail.com on 12 Nov 2006 at 8:49

[GoogleCodeExporter]

cdparanoia 16 -d /dev/cdrom -O 0 /Sjø/track1_2.wav

Is that the command rr sends to cdparanoia to rip the 16th (in this case the 
last)
track of the disc?  Grip, aside from being a mess, worked.  So did the command 
above.
 But where does rr insert the extra cdparanoia options?  I did:

cdparanoia -Z 16 -d /dev/cdrom -O 0 /Sjø/track1_2.wav

and it all worked.  Same discs fails with -Z used with rr.  If I had to guess 
I'd say
whatever command rr gives to cdparanoia makes it stall in some way.

Original comment by mordbr...@gmail.com on 12 Nov 2006 at 9:37

[GoogleCodeExporter]

The command send to cdparanoia would be exactly the same:
cdparanoia -Z 16 -d /dev/cdrom -O 0 /Sjo/track1_2.wav

Ofcourse I could enable a workaround that would remove the -Z setting if the 
last 
track is ripped. But I'll look into this issue some more.

Original comment by rubyripp...@gmail.com on 12 Nov 2006 at 2:38

• Changed state: Accepted

[GoogleCodeExporter]

if it's exactly the same then I don't see how the problem is occuring.  I mean 
what
difference is there between issuing that command in the terminal and having rr 
issue
it?  Very strange.

Original comment by mordbr...@gmail.com on 12 Nov 2006 at 10:06

[GoogleCodeExporter]

IMO disabling -Z for the last track would be a last resort, as there are some 
discs
that have tracks which won't rip without it.

Original comment by mordbr...@gmail.com on 13 Nov 2006 at 1:26

[GoogleCodeExporter]

I suspect that cdparanoia is somehow giving a return code too early that 
indicates 
it's finished. When I have some time I'll test it for myself.

Original comment by rubyripp...@gmail.com on 13 Nov 2006 at 10:26

[GoogleCodeExporter]

Maybe.  Maybe cdparanoia never gets far enough to send the return code either.

[jebediah@manger]-(~/src/rubyripper/svn)$ ./rubyripper_gtk2.rb
cdparanoia III release 10pre0 (August 29, 2006)
(C) 2006 Monty <monty@xiph.org> and Xiph.Org

Report bugs to paranoia@xiph.org
http://www.xiph.org/paranoia/

Ripping from sector  181914 (track  4 [0:00.00])
          to sector  235779 (track  4 [11:58.15])

outputting to /Sjø/rr/track4_1.wav

 (== PROGRESS == [                             >| 235779 00 ] == :^D 0 ==)

It's just sits there like that... disc keeps spinning too.

Original comment by mordbr...@gmail.com on 14 Nov 2006 at 9:39

[GoogleCodeExporter]

I'm sorry, but I can't reproduce all this (see the log files). As I understood 
this 
happens for you with EVERY cd. Therefore the bug is probably within cdparanoia. 

You aren't by any chance using an offset for your drive? Could you try turning 
it 
off and see if it helps?

Original comment by rubyripp...@gmail.com on 15 Nov 2006 at 2:41

Attachments:

• ripping.log
• ripping.log
• ripping.log

[GoogleCodeExporter]

ugh, that was exactly it.  Offset seems to trigger the bug in cdparanoia.  Feel 
free
to mark this not a bug.

Original comment by mordbr...@gmail.com on 16 Nov 2006 at 10:58

[GoogleCodeExporter]

I suppose I could simply close the bug, but then again: a workaround should be 
nice, right?

As I understand it now, cdparanoia in combination with the -Z switch always 
hangs 
when an offset different than 0 is used on the last track.
A solution would be to check for this circumstances and only then remove the -Z 
option from the ripper options.

Original comment by rubyripp...@gmail.com on 16 Nov 2006 at 5:44

[GoogleCodeExporter]

I think a warning would be suitable.  If offset is specified and -Z is 
specified in
the options then issue a warning that disc might hang.  Then the user can 
decide what
action to take.  Something tells me there are more of these incompatibilities we
haven't discovered or there will be more in the future.  Would warning be 
easier from
a coding standpoint too?

Original comment by mordbr...@gmail.com on 17 Nov 2006 at 10:14

[GoogleCodeExporter]

I can reproduce the hang here when I supply the offset for my drive and use the 
-Z 
parameter. Since nobody ever wants to have a hang, the -Z parameter is 
automatically removed when the last track is ripped. This will still lead to 
correct results, only a bit slower.
About the warning message: I think it would be sufficient to note this in the 
README file, which i will supply soon. Rubyripper has plenty of warning 
messages 
already ;)

Fixed at revision 19.

Original comment by rubyripp...@gmail.com on 18 Nov 2006 at 2:35

• Changed state: Fixed

[GoogleCodeExporter]

Shouldn't you at least make note of it in the debug?  Be simple to just have it 
print
something when it switches it off (or so I'd think).

Original comment by mordbr...@gmail.com on 19 Nov 2006 at 9:25