Page 1 of 1
Where is the error likely here??
Posted: March 5th, 2012, 5:41 am
by astrodog
Looking for a little advice....
I was trying to dl a 14GB mkv file today (72 rar parts, with par2 set)
Ended up 11 repair blocks short, pretty much every rar file was corrupt, missing 2-5 repair blocks or so.
I tried re-downloading the worst affected rar file, only to get the identical error from 3 different news servers, (astraweb/giganews/blocknews).
Is this likely a dodgy nzb file (nzbindex.nl) or DMCA takedown ?? doesn't seem to be a retention issue, post was only 240 days old.....
Just curious now.... decided not to throw anymore precious quota after this one!
Re: Where is the error likely here??
Posted: March 5th, 2012, 1:36 pm
by shypike
This is not unusual.
However, sometimes SABnzbd is thwarted by some irregular naming schema for the par2 files.
You can check this by looking at the file list.
The next major release will have a crude (and slow) pre-check to detect bad posts like this.
If your 3 servers gave the same results, then the poster must have screwed up.
Didn't nzbindex.nl give any indication on completeness?
Re: Where is the error likely here??
Posted: March 5th, 2012, 6:51 pm
by astrodog
nzbindex.nl didn't report any deficiencies, the annoying thing is that every RAR file showed up as dead on 200MB as they were being downloaded (I was keeping an eye on it, thinking all was grand!)then to find I missed by 40MB in 14GB....
I checked it with a different par2 client, exactly the same result....
I'd love to see the program pause if the first x no of parts aren't complete - why would it be slow though?? - when I run a par2 check on a single part like this, only takes several seconds to see if its complete...
Re: Where is the error likely here??
Posted: March 6th, 2012, 6:08 am
by shypike
Pre-check means that SABnzbd asks the server whether it actually has the articles.
Any strategy based on guessing the missing percentage based on what's already downloaded
is very unreliable. It assumes patterns in missing articles.
Any method (including the pre-check) is also made unreliable by the fact
that article sizes and par2 data unit sizes do not correspond.
So given one missing article it is not possible to know whether this hits one or two
par2 data units. Also the par2 data unit size is not known beforehand.
Re: Where is the error likely here??
Posted: March 6th, 2012, 5:14 pm
by astrodog
shypike wrote:Any strategy based on guessing the missing percentage based on what's already downloaded
is very unreliable. It assumes patterns in missing articles.
For sure.... may just give you an idea I guess, for those of us on download limits, it may just make us keep looking for an alternative dl.....
Nothing to stop me pausing the dl after a few parts and manually checking them....
Re: Where is the error likely here??
Posted: March 8th, 2012, 9:07 pm
by pobox
I'm curious about debugging the "bad" post itself but can go no further because it's against the forum rules for me to know what it was.
Re: Where is the error likely here??
Posted: March 9th, 2012, 5:57 am
by shypike
There's no problem with PM-ing each other with this info.
Re: Where is the error likely here??
Posted: March 9th, 2012, 7:49 pm
by pobox
Thanks for the PM. You were 11 blocks short, but I don't know if you downloaded the sample. The poster included the sample in the PAR2 source files. NZBIndex.nl has two NZBs, one for the sample and one for the rest of the post. The sample has 44 good blocks out of 45. The post was uploaded with a defective yEnc encoder (yenc-vanilla for Newsmangler) which occasionally drops the first byte of an article. This defective yEnc encoding module should be stamped out because it continues to be distributed with Newsmangler years after it first appeared. The sample itself happens to be missing 1 byte (from article 444 of 447) and when played the missing byte appears as a glitch in the video.
Re: Where is the error likely here??
Posted: March 9th, 2012, 8:55 pm
by astrodog
Thanks - I didn't download the sample, when looking for high def stuff, I size restrict the nzb index to cut through the dross - I guess in this case getting the sample would have helped though? 44 blocks that wasn't needed from the par2 set.... might try it again later on....