Cosmetic: Number of available repair blocks misleading in History

[onebinary]

When a repair fails due to insufficient repair blocks, the wording on the output in History is a bit misleading.

Code: Select all

Stage Par2
    [PAR-INFO] filenamefix.proof: => Repaired in 0.0s
    [PAR-INFO] filename-OTHER: => Not enough repair blocks left (have: 0, need: 17)
    [PAR-INFO] filename: => Verified in 9.4s, all files correct
    [DEL-INFO] filenamefix.proof: => Deleted 3 file(s)
    [DEL-INFO] filename: => Deleted 2 file(s)

Code: Select all

Repair is required.
2 file(s) are missing.
2 file(s) are ok.
You have 2 out of 28 data blocks available.
You have 9 recovery blocks available.
Repair is not possible.
You need 17 more recovery blocks to be able to repair.

Instead of saying 0 out of 17, I think it should say 'have: 9, need: 17 more'.

[shypike]

Is this actual output?
Can you send me an uncensored log and/or screenshots that show this behaviour?
bugs at sabnzbd.org

[onebinary]

That is real output with a s/uncensored/filename/

I'll work on getting log tomorrow (debug is a bear to filter).  Should be fairly easy to reproduce though, find something that has a separate par2 set with a sample file in it, enable the 'ignore sample files' option, download the files, and you should hit the 'not enough repair blocks' scenario.

In searching through newsunpack.py at the logging lines, I think I might have narrowed down what is going on:

Code: Select all

onebinary@home:/data/sabnzbd/logs$ grep -i "blocks available" sabnzbd.log*
sabnzbd.log.4:2008-09-27 21:39:26,345::INFO::[newsunpack] 8 blocks available
sabnzbd.log.4:2008-09-27 21:39:38,061::INFO::[newsunpack] 0 blocks available

So after it downloaded the 8 available blocks it probably did a par verify again, that failed, so it checked to see if there were any more blocks to download, there weren't, and the avail_blocks variable got set to 0.