SABnzbd Forums

I like this idea, filed as #392.

This is great, but I point you guys here with a confused look on my face. 

Anyway, looking forward to this being implemented someday.

Hence my 'someday' .  I'm just glad the idea has been recognised as useful.
I'm still confused why it's ok now and wasn't ok earlier mind you.

rollingeyeball wrote: Hence my 'someday' .  I'm just glad the idea has been recognised as useful.
I'm still confused why it's ok now and wasn't ok earlier mind you.

I need to do some research on if we really can't tell the difference between passworded and broken. If we can't, then shypike is right and there's no easy logical way to do this.

rollingeyeball wrote: if we really can't tell the difference between passworded and broken

In WinRar Information
(Alt+I)

password: present

^ if passworded.  AFAIK does not show present for damaged.  If pass PAR checking and still password=present fair to assume archives not-damaged and passworded?

http://www.win-rar.com/index.php?id=24&kb_article_id=99

I get an error like "CRC failed in the encrypted file (wrong password ?)"!


RAR cannot distinguish a corrupt file and wrong password. If it were possible, it would make encryption weaker. Therefore, such a message may indicate both a wrong password and a corrupt file.

Check to see if you have installed the recent version. If not, please download the actual WinRAR/RAR version here. We always improve all functions with every update.

Maybe the rarlabs people will share updated information as this is a bit outdated
http://www.win-rar.com/index.php?id=24& ... cle_id=162

Such detection is possible, but you have to understand how hard it
would be to implement it.
SABnzbd tries to utilize as many ports as possible to one the  first
article of a file is in, the next 20 or 30 are already in or nearly in.
That wastes bandwidth, but worse: such a detection scheme just doesn't
fit into the segmented design of SABnzbd, where downloading is
separate from decoding, which is separate from assembling and even
more separate from post-processing.

So it is possible to implement it, but it would be very hard and create
a messy design. I doubt that's worth it.