This is something I've experienced for quite a while now, and it still happens with 0.42.0. It should be easily reproducible as the cause is straightforward, the combination of multiple individually parred files within an nzb with the 'unrar to different folder' option enabled. I took a look at fixed bugs, and outstanding bugs, and was unable to see a matching thread.
This problem can be worked around by disabling the 'unrar to different folder' option, which avoids the cause (moved nfo files for as yet to be unrarred/repaired pars).
When the 'unrar to different folder' option is enabled, and alt.binz unrars the first parred file and moves it to a different folder, it moves all the nfo files for all the other parred files as well. This then causes alt.binz to get very very confused.
alt.binz will get into a state where even if those nfo files are copied back, it will miscalculate the number of available blocks/required blocks in the par tab for all the remaining parred files. It may sometimes do the popup dialog about the collection being paused because of insufficient blocks or files or whatever. Opening up the par2 files outside of alt.binz will show that there are sufficient blocks for repair, but alt.binz will still be unable to repair those files. Even if the nfo files are copied back and alt.binz manages to repair/unrar another parred file, all the nfo files will be moved again. But eventually, I can hand manage the complete set of parred files out of alt.binz, even if it means using an external par tool and just using alt.binz to get the missing blocks, then hand repairing with the external tool and unrarring with 7zip.
I think this is a pretty simple one to reproduce, the last collection I had this occur on was 274152 / iZombie.S01.DVDRip.X264-REWARD nzb posted by the alt.binaries.teevee group. It also happened for 310200 / The.Expanse.S01.BDRip.x264-DEMAND.
No firewall, and Windows 10.
