NewsBin deceives itself with renaming

[RayMark]

Perhaps you could reconsider the renaming scheme where not the new file is renamed but the old one instead. It destroys the integrity of descript.ion information.
And I really think that if NewsBin generates descript.ion it should contain correct information inside.

But in some situations NewsBin even deceives itself with this renaming scheme. For example, sometimes several posts have the same names and are only later renamed to correct names by par2.
It is OK if they are downloaded one at a time. But if the whole bunch of them is put into the download list together and not paused, mix-ups happen:
somehow par2 checking process renames such a meaningless name to the real name but at the same time also renames to -(0001) name as a new file with the same name is downloaded and a different - wrong! - file (downloaded later) is renamed by par2 instead.

So, for example after par2 renaming I get

some.show.s01e03.r40
which actually contains inside it:
some.show.s01e04.sfv
and actual some.show.s01e03.r40 remains named something like 206220-(0001)
Clearly, after the 206220 file was par checked and was about to be renamed to some.show.s01e03.r40, just before that it was renamed to 206220-(0001) and substituted by a different 206220 file which was renamed to some.show.s01e03.r40 instead.
So, some.show.s01e03 remains not unrarred because one rar part is bad and not enough par2 blocks to replace it whole.
Here a second par2 check attempt would be helpful, but it does not happen.

Such a situation is difficult to replicate because everything depends on timing, but I had such occurrences many times with various NewsBin builds including the latest beta 7, although I learned to avoid them by downloading such posts one-at-a-time.

BTW, thanks for beta 7. Finally! With this new dedicated thread, I am yet to see a single "pending" line in the download list. Although I haven't tested with slow usb 2.0 drive yet.

[Quade]

But in some situations NewsBin even deceives itself with this renaming scheme. For example, sometimes several posts have the same names and are only later renamed to correct names by par2.
It is OK if they are downloaded one at a time. But if the whole bunch of them is put into the download list together and not paused, mix-ups happen:
somehow par2 checking process renames such a meaningless name to the real name but at the same time also renames to -(0001) name as a new file with the same name is downloaded and a different - wrong! - file (downloaded later) is renamed by par2 instead.

Maybe you should strive to download each set into a unique folder so collisions don't happen?

[RayMark]

Yes, this solution occurred to me as well. But I did not use it. The frequency of collisions did not force me to (yet?).

To me, the incorrect information in descript.ion files is worse. Because it occurs much more frequently than those collisions.
But still, descript.ion file is very useful. I use it frequently. Even though I hate its limitation related to renaming.

The question about those collisions is this: why NewsBin does not retry par checking on bad / incomplete parts?
With just a single retry the collision would be fixed, because the correct file is present under a different name.
Or at least the manual invocation could be better integrated? Instead of running QuickPar, force internal re-check and if successful - continue with unrarring.

Retrying par checking would help in other (slightly different) situations as well.
Sometimes there are duplicate posts of the same thing, and sometimes one of those posts is incomplete or has bad rar parts.
And sometimes I (accidentally or not) put both to the download list. So sometimes so happen, that good rar parts are renamed with -(0001) and bad rar parts (in uppercase) - without -(0001) (so downloaded later?) and NewsBin does not unrar the whole thing even though an external QuickPar or MultiPar easily finds that all parts are complete and only renaming is needed.
I had quite a few of such cases. Possibly, also when both attempts incomplete but they complete each other.

[Quade]

What you seem to be asking is "why can't newsbin fix every possible way a download can screw up".

The answer is simply that I've never screwed the downloads up that way so, there's no support for fixing it. I'd say downloading 2 identical sets at nearly the same time falls under "That's not recommended". If you know you're going to have name collisions and you know that name collisions are a problem. You should avail yourself to the ways Newsbin has built in to avoid name collisions.

I read your comment and see what looks like "I know I can fix the name collision problem but I choose not to right now" and wonder why you choose not to fix it?

[RayMark]

I guess, downloading each post to a separate folder would fix even the descript.ion problem.
But it is so inconvenient. I guess, the unraring can be done to a common for every post folder again, improving things a bit.
But these are workarounds. The burden is shifted to the user. If NewsBin is supposed to be suitable for automated mass downloads, it should be able to handle situations arising during such downloads.

But I was asking a separate distinct question: why can't NewsBin make a seamless second attempt of par checking? It would allow it to handle successfully most of those issues.
I guess, the par2 checking is too integrated with assembling / decoding and the second attempt would be more similar to invoking an external tool which is allowed via the right click?
But that is, again, sort of workaround.

BTW, you really should invoke MultiPar, not the ancient QuickPar. MultiPar is much much faster (feels like 100s times faster) both when checking and when repairing (CUDA cores!) and can handle some par2 files that OuickPar does not even recognize as valid par2 files.
I think MultiPar is just a GUI for parchive, so you can use internally parchive libraries directly if you do not already

[Quade]

But it is so inconvenient. I guess, the unraring can be done to a common for every post folder again, improving things a bit.

This is my thought. Download to unique and unrar to common.

But I was asking a separate distinct question: why can't NewsBin make a seamless second attempt of par checking? It would allow it to handle successfully most of those issues.

Every time a PAR downloads, Newsbin re-checks to see if it can repair and/or unrar. By downloading two identical sets at the same time, probably with the same pars even, you completely muddled the process. I'm not sure it would even work if you used unique folders. If you really want to add multiple identical sets, you probably want to pause some to let them go first.

BTW, you really should invoke MultiPar, not the ancient QuickPar. MultiPar is much much faster (feels like 100s times faster) both when checking and when repairing (CUDA cores!) and can handle some par2 files that OuickPar does not even recognize as valid par2 files.

Newsbin doesn't use either one. When you tell Newsbin to pop up quickpar, it actually invokes whatever program is currently registered to process PARS. It's not actually used for processing internally. I don't like to invoke external programs for core functionality. Newsbin is already much faster than Quickpar for numerous reasons including multi-core repair. Quickpar can't handle long path and/or foreign characters either.

[RayMark]

Every time a PAR downloads, Newsbin re-checks to see if it can repair and/or unrar. By downloading two identical sets at the same time, probably with the same pars even, you completely muddled the process. I'm not sure it would even work if you used unique folders. If you really want to add multiple identical sets, you probably want to pause some to let them go first.

Not that I want to. Sometimes it just so happens.
But re-checking again would solve the issues with my original problem, when different posts have the same rar names but are later renamed. The collision issue. It is easily solved by the second par2 check because the missing rar part is present in the download folder, only under the 206220-(0001) name in that example.

So this second check solves both the problems and perhaps various similar others, because I had quite a few such unrrared posts left in the download folder where running external MultiPar fixed everything. The reasons why NewsBin failed - not clear, but usually there are some -(0001) files present in such cases, even though I think there were no duplicate posts downloaded together. But who knows what is gathered together in a collapsed post. Sometimes duplicates show up only when expanded - I am pretty sure of that.