Par2 matching algorithm confused by some Downloads

[User321]

Hi,

A friend asked me today: have you noticed a window popping up in Alt.binz stating "Collection is being paused because it is damaged and there aren't enough par2's"?
I said no, but i have a feeling what might be causing this, send over the NZB(s)!
So I turned on the option under Misc.#3 to pause the collection when there aren't enough par2, and set off testing..
3 files into the download, I got the same window.
- OK, but how could alt.binz know this already? (I had only downloaded 3/80 files (5 blocks missing out of a total 1978), with 198 potential extra blocks in par2 files)


So i tested further:
1. I disabled that option
2. Downloaded the entire thing
(During this, i notice the files being written to my drive have a different name.. not only the rars, but they come in as differently named files, which then get renamed to the correct rar name by altbinz' par2 function)

3. So far so good, I end up with a collection of files, that amasses to 1820/1978 blocks, but no par2's have yet been downloaded.. so I unpause all of them.
4. I ended up with 2002/1978 blocks, so alt.binz tries it's best to repair the collection, but fails..

probably because the collection looks like this (all differently named .par2's)

5. Just as a check, I scanned and repaired the collection with multipar (had to manually add the differenly-named pars, but then it succeeded)

So, i'll make a few assumptions based on my findings:
- The poster of these particular NZB's is trying to avoid DMCA by A. having a different filename in the subject than is actually posted, and B. also depends on the files being autorenamed by a par2 function of the newsreader (he appears to be succeeding, *most* of the files are still up)
- Alt.binz' par2 feature only tries to download extra par2 files from a collection if they have the same name (this is usually good behaviour, as it's possible to have different sets of rar/par in a collection)
- It takes that name from the subject line in the nzb (in this case, a bad thing)
- The "pause the collection" feature relies on the par2 feature, so fixing 1 should fix both?

Now, would it be possible to:
1. Implement a subroutine where: if downloaded small .par2 filename does not match the one in the subject, then don't match for exactfilename.vol**.par2, but *.vol**.par2 to find extra par2 volumes
2. Have the included par2cmdline handle differently-named volumes, since apparently the index function in the par2 tab already does?

If you need the NZB(s) involved, send me a message.
Not sure if relevant: I'm on Windows 10 Pro, Windows firewall, Latest alt.binz (0.43.2)

[dabrown]

I have a similar problem when downloading obfuscated posts from one particular NN indexer who uses a similar method to protect their posts, both to avoid DMCA and also from other indexers from being able to scrape newsgroups and indexing their unique posts - your example looks much the same.

Where the issue arises, if the any of the rars require par2 repair, the only way I have been able to do this, is to manually copy the .par2 main file name and paste it over the top of the differently named parity volume files, leaving the .volxxx+xx.par2 part of each of the file names intact.

A manual repair can then be started by going into the par2 module in Alt.Binz, right-clicking on the file name and selecting Repair PAR2 set and that will then usually correctly repair the set (providing you have enough parity volumes).  I remember that a long time ago, Quickpar could detect if the par2 files were named incorrectly, and rename them accordingly - the customised version of par2cmdline that Alt.Binz uses may not be able to achieve this, or might require some parameter tweaks?  I have a suspicion this might not work with these particular obfuscated nzb files, but only rdl would be able to answer this.

Some people would argue what I do as a "work around " is far from ideal and requires much too much manual interaction, but it works for me, I have not yet found an easier or more automated way to deal with these posts, however, I am open to suggestions.

As you point out, if you utilise the "Pause the collection when there aren't enough par2" option, that will cause that download to stop/pause due to reasons as you have detailed in your post.

At one point I attempted to use Multipar to repair these posts, but even that only picked up one of the parity volumes, so manually renaming as I have suggested above and then using Alt.Binz's par2 module to repair and then unrar does work, albeit requiring more manual interaction.

The other thing I often have to do manually is delete the variously named parity volumes which are left behind after the par2 cleanup since they have different names, and Alt.Binz does not know to remove them as part of the clean up process.  That potentially could be achieved by changing the clean up option to delete "*.par2".

As a side note, I always download some parity volumes for each and every nzb regardless since often .nfo files aren't posted but it might be a part of the parity set (when it was created).  I have found by downloading some parity volumes this speeds up the process for repair and unrar if one, two or more blocks worth of parity volumes are already present, Alt.Binz often doesn't need to fetch any additional parity volumes after it has completed it's first check of the files.

I figured I'd just add my personal experience to say I've seen something very similar and this is how I deal with it. 

Other binary newsreaders must experience a similar problem when encountering these particular nzb files, but I've never heard anyone using complaining about it.  As final step, I usually have to manually rename the unrared obfuscated .mkv file name based on the folder name - there may be an option to do this automatically, but I'm not sure any exists - looking at the unrar options they are all about creating a subfolder based on group name, NZB name, or Archive name - but I want to rename the actual extracted .mkv file so that it is the same as the extracted folder name or the same as the original NZB name, so this is more of a post processing option, and getting off the track.

Regards.