Summary incorrect

[GoogleCodeExporter]

What steps will reproduce the problem?
1. rip cd that ends up having suspicion positions
2.
3.

What is the expected output? What do you see instead?
Summary lists wrong track and lists the output twice.

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

Please provide any additional information below.
See attached file.

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

Attachments:

• ripping.log

[GoogleCodeExporter]

The summary code is quite new, so it's no surprise some finetuning has to be 
done. 
If you have any other thoughts on improving the log output, you're welcome to 
say 
so.

Original comment by rubyripp...@gmail.com on 9 Nov 2006 at 9:48

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I'm sure there is some; I think I recall some redundancy but as it's low 
priority I
will look into it later.

Original comment by mordbr...@gmail.com on 9 Nov 2006 at 11:01

[GoogleCodeExporter]

An extra verbose log option would be swell.  Have it also include all the 
output from
cdparanoia or cdda2wav to the file as well.  Then a user could just look at the 
file
to see if the disc is prolematic at all.

Like with this one track:
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  124239 (track  4 [0:00.00])
          to sector  165075 (track  4 [9:04.36])

outputting to /Sjø/rr/track4_1.wav

 (== PROGRESS == [V                            +| 165075 00 ] == :^D * ==)

Done.

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  124239 (track  4 [0:00.00])
          to sector  165075 (track  4 [9:04.36])

outputting to /Sjø/rr/track4_2.wav

 (== PROGRESS == [V                            +| 165075 00 ] == :^D * ==)

Done.

It all compares fine but there is no way of seeing what exactly happened without
looking in the terminal.

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

[GoogleCodeExporter]

Just FYI, the track in the above example doesn't rip right.  It's probably a 
poor
(cheap) pressing and now fault of rubyripper of course.  cdparanoia seems to 
work
around the scratch by skipping forward a few blocks; using -Z gets a correct 
rip.

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

[GoogleCodeExporter]

ugh, I'm so out of it I posted before finishing my thought.  Anyway, the reason 
why I
like to look at the cdparanoia status line is exactly for reasons like that. 
According to rubyripper everything is swell, but that actual ripping command 
shows
otherwise (even if they do match).

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

[GoogleCodeExporter]

Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.
Suspicion position at 05:23.

Why not condense these into one line that says something like "X suspicion 
positions
at 05:23" where X is the number of Suspicion lines for each time.  It will keep 
the
log size down and make it more readable.  In this case the log for that disc 
was 575
kb for over 20000 lines!  Most of it is duplicitous.

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

[GoogleCodeExporter]

Yup, keep 'm coming. I also made one up myself: if the amount of matches for 
erronous positions is bigger than non-erronous positions, the log file can be 
smaller.
Say match all chunks = 2 and erronous chunks = 5
When errors are found after trial 2, no matches will be found ofcourse in trial 
3, 
4 and 5, so skip this info.

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

[GoogleCodeExporter]

I should clarify on having the cdparanoia / cdda2wav output in the log file.  
Not the
whole thing but just the status lines; something like this:

Track 05, trial 01:
 (== PROGRESS == [V                            +| 165075 00 ] == :^D * ==)
Track 05, trial 02:
 (== PROGRESS == [V                 +          +| 165075 00 ] == :^D * ==)

and so on.  Maybe there is a better way to do it too.

Original comment by mordbr...@gmail.com on 15 Nov 2006 at 7:00

[GoogleCodeExporter]

I've rewritten a lot of relevant code to better match our wishes. The 
cdparanoia 
output isn't covered by this. Can you open a separate bug for that?

Original comment by rubyripp...@gmail.com on 19 Nov 2006 at 1:33

• Changed state: Fixed