Sorry, no log available here as well. However I can add the following.
In one case when I saw a rarset had 1 bad block in one file (while other files of the same set were downloaded), I manually checked the rarset with quickpar. It checked out OK (no errors on the file that was suposed to have a bad block). After that I exited Alt.Binz and reopened it. After Alt.Binz rechecked the rarset, the file that was suposed to have a bad block was found to be OK this time.
So I don't think the problem has to do with the nzbs, or the files, but with the way the files are par2-checked. It seems that under some conditions (not known yet) the result of the par2 check of some files is not correct and good files are marked as bad and bad files as good.
There also seems to be a second bug here, that should be easier to find. I saw the log for this example, but haven't kept it. What I read was the following, as I remeber it:
1. One file is found to have a bad block after it is downloaded (which was a false reading as it turned out, which is the first bug).
2. After all the files are downloaded, the needed par2 blocks are downloaded.
3. Then a repair of the rarset is initiated, however no bad files are found ("no repair needed" reported in log)
4. After that, there is no attempt to unrar the release (This is the second bug. Maybe Alt.Binz expects another exit code from par2cmdline, after the repair, e.g. repair successful, or something like that and that's why it does not start the unrar process).