nzb of nzb with par2 of end set

nomandera commented 5 years ago

There are use cases where a nzb may contain just an nzb. For instance if the posting is many small files you will often see it concluded with a "helper" nzb.

In this scenario the parity files may be created against the data set and not the posted helper nzb.

As an example helper nzb as "posted and packed by an indexer":

"2018-12-06.vol011+010.par2" yEnc (1/7)
"2018-12-06.vol006+005.par2" yEnc (1/4)
"2018-12-06.vol003+003.par2" yEnc (1/3)
"2018-12-06.vol001+002.par2" yEnc (1/2)
"2018-12-06.vol000+001.par2" yEnc (1/1)
"2018-12-06.par2" yEnc (1/1)
"2018-12-06.nzb" yEnc (1/1)

2018-12-06.nzb would contain the articles for the actual data set and 2018-12-06.par2 would repair the same data set but not the helper nzb.

Because of the naming and the logic of this posting sequence nzbget becomes confused and parity fails and so does the download.

It is even worse as the indexer nzb of the posted helper nzb 2018-12-06.nzb is often identically named also as 2018-12-06.nzb causing dupe detection to kick in immediately.

I am at a loss how to cater for this as-is. Tools exist such as https://github.com/Tensai75/AddNZBs.py but they add new queue items breaking the repair path and suffering from teh same dupe detection.

Ideally there is a flow here where the helper nzb is downloaded and live-merged with the indexed nzb so that ultimately the data set is downloaded within the same single session so that the parity file work.

hugbug commented 5 years ago

I am at a loss how to cater for this as-is.

The best approach would be to contact the indexer and explain them how to create such nzbs properly (under a different name, without par2-files).

Other than that you can write extension scripts for NZBGet to handle such cases. For example a scan-script to process the nzb before it is added to queue could rename the nzb-file and remove par2-files. Provided you can identify such nzbs from the script.

nomandera commented 5 years ago

This is what I was afraid off. I am capable of hacking together something that will work for me but wouldn't be even close to be generic enough to help others.

As far as I can tell the indexer is doing it job right and the issue is the scheme that the poster(s) are using.

Thinking out loud, in plain English, I think the most universal solution is:

If a posting contains only parity and nzb files rename the nzbget entry to signify this then check the parity contents...

if the parity contains reference to only the nzb continue as normal
if the parity contains reference the nzb and other files check the crc of the nzb only (obviously repair unlikely)
if the parity contains no reference to the nzb split out the parity files to a separate nzbget download and pause it

on completion of nzb only download immediately queue the downloaded nzbs in the same category as the initial

Realistically I am not capable of pulling all that together. Let me know if there is any chance of help and if not I will close this ticket and post and kludges I manage to find.

hugbug commented 5 years ago

I think you could do something simpler: if nzb contains only other nzbs and par2-files - remove all par2-files from that nzb.

nzbget / nzbget

nzb of nzb with par2 of end set #586