Currently, pausing stops downloading but does not stop decoding, moving from cache to the download destination, repairing and extracting. Sometimes I have hundreds of gigabytes already downloaded but still in cache. So it can take hours untill NewsBin really stops after hitting "pause". You see the problem? "Pause all activities" option would be nice to have.
And sometimes NewsBin is doing something when it is doing nothing, or so it seems. It would be good to be able to stop it doing nothing as well
For example, I noticed Newsbin (6.73 Final) continuously using 12-13% CPU even when every item in the download list is paused and the downloading globally is paused as well.
Nothing is being downloaded, repaired or extracted - or so it seems.
Well, it happened after I downloaded a 600 GB post and NewsBin was waisting time periodically going into repair mode at 0% - then the CPU usage would go up to 28-29%.
It is rather strange, if it was just par2 checking, I expected NewsBin to do the checking one rar file at a time when a file was written from the cache to the destination disk. Furthermore, the sufficient number of par blocks was already shown - so already checked? And all the files already written to the destination location. And the files were all OK - I checked myself with an external tool. So why the "repairing" stage?
Anyway, NewsBin was doing this 29% CPU 0% progress repair thing for a long long long time, so I paused it. And it stopped doing it, but CPU usage remained @ 12-13%. There were no indications that there was any activity with that download, though.
It remained @ retries: 0, N: 10 - whatever that means. And no more "repairing".
BTW, when I tried to run a par2 check on that download myself, QuickPar was not showing any data files, as if par2s were corrupt or something. Perhaps NewsBin also had some issues with those par2 files. But MultiPar had no problems (they were par2s, not par3s!). It checked all 2000+ 250 MB rar parts using only 12% CPU.
Everything was OK, no repair needed. External unrarring used only 4% CPU.
So the 29% CPU usage when "repairing" good files, and then 13% CPU usage when doing nothing - looks strange. And excessive, even if NewsBin were doing something useful, but it was not.
Also, for some reason NewsBin downloaded quite a few unnecessary par2 blocks: 175 blocks - enough to recreate at least 13 missing rar parts, but none were missing.
But still, not all available par2 blocks - it is possible that it kept downloading new ones after each iteration of this "repairing" attempt - I've seen similar (also wrong?) behavior with password protected rars. But these were not password-protected.
