SABnzbd Forums

I've been downloading a few season packs, but SAB is only extracting a single episode to extract from them. I was going to try 7zip on them, but these are not RARs and have number extensions with PAR2 files. Is the NZB messed up or do I have a setting incorrect someplace which would cause this? Comments on the NZB seem to indicate that others have been able to get more than a single episode.

Thanks!

Maybe try turning off processing in the drop down for it and repairing/unpacking it yourself.

Thanks for the info. I did a lot of searching I believe I figured out how to manually repair/unpack them. If I were going to do this for the problem NZBs, I'm guessing I would switch them from +Delete to Download instead, right?

Now, I found "AutoUnpack" and when opening one of the problem NZBs there, I see 0% complete and 0/# missing for everything, plus a status of "Repair failed (or there is no PAR-set)". However, somehow, SABnzbd was able to unpack a single episode which AutoUnpack also says is missing. So, I opened up each PAR file one-by-one in QuickPar and that repaired and unpacked the majority of the episodes. At that point, there were still a bunch of RAR files QuickPar unpacked and left as such, which 7zip was then able to extract a single episode from, giving me most of the season. Should SABnzbd have been able to do this on its own? If not, can someone explain why so I understand? And, if it should have been able to, any idea what I may have set incorrectly? I'm very new to this, so thanks for taking the time to walk me through this.

Switching form +Delete to Download was the right idea.

It sounds like instead of there just being a bunch of rars and the associated pars for everything, there were individual rars and individual pars for each episode. I'm not sure how SABnzbd handles that as I've never really encountered it, so someone with more knowledge would have to chime in

Thanks for verifying and you're correct. There were about 15 PAR2 files I needed to load into QuickPar, which was able to extract the majority of episodes into a usable state. Via one of the PAR2 files, QuickPar unpacked a bunch of RAR files for a single episode, which I then unpacked using 7Zip. I'm still messing around with settings to see if I can figure out why SAB couldn't/didn't unpack these on its own, but I don't seem to be making any progress.

A little more info, in case it would help. I'm using SAB with SickRage and I initially had SAB not doing any scripts, such as sabtosickbeard.exe, but had SickRage set to monitor the SAB completed folder for files and move/rename them. This was working fine for single episodes and that's how it was when I noticed the issue with season packs. I also tried it with the script, turning off the sorting in SAB, turning on the sorting in SickRage, and other combinations of those three items, with no change in behavior for new season pack downloads.

Anyone else have an idea what I've got screwed up?

I'm interested in the NZB file of this download.
Can you email it to [email protected] ?
(Please add the URL of this post.)

Email sent. Thanks for checking it out. Hope I'm not wasting your time with something stupid that I'm doing wrong.

It's the poster or the indexer that screwed up.
The NZB contains several files with identical names with different context.
Now SABnzbd has a way of dealing with duplicate file names, but the
order in which the files are completed, makes a difference.
This order is not entirely predictable, especially not for smaller files.
This means that SABnzbd cannot keep full track of which files belong to which set.

How this NZB is exactly handled by SABnzbd, I don't know.
Since it's about 60G big, I'm not downloading it without a very good reason.
I may have a look at it later.
Interim conclusion: this is a sick post and you're not to blame.

Glad to hear and thanks for taking a look! I've seen 2 other season packs which behaved like this one, but the NZBs were deleted already and I can't recall which ones they were. Would you want me to update this thread with further occurrences? (They'll most likely be similarly large ones.)

I have enough for now.
I will schedule it for nightly downloading and then I need time to analyse.
The end result may very well be that such downloads cannot be handled.
Just maybe it's a simple oversight that can be fixed.

Not trying to push you in any way, but this is happening pretty regularly for me any time I add a new series or season, so I thought I'd come back with an alternative, in case you couldn't find a way to handle these (which would obviously be the preferred solution). I was wondering if there would be a way to flag these via an option, so that they don't get deleted like others. I could see this being handled with something like, "If a specified category results in only a single file being pulled from a download >x[MB,GB], don't delete (and maybe send email?)." I realize it's a specialized scenario, but this might come in useful for others who download fairly large files (by their own standards) which have some kind of issue and would allow them the ability to analyze it further and avoid a big re-download.

Just an idea, in case you can't see a way to process these internally.

Not deleting large posts when not fully processed makes sense.
I'll look into it.
There will not be a complete solution, given the way your example NZB was structured, there cannot be.

Awesome! Thanks for considering it. I suspected there wouldn't be a complete solution, based on your original reply about the situation, so I started thinking about alternatives. I actually thought about it a little further and it might make sense for these problem posts to be moved to some sort of a problem folder designated by the user. This could be used for additional reasons (e.g. password protected files), but I mainly see it as a way to free up space in the temp folder, so other jobs don't run out before we get a chance to look into the problem.

I think that for password-protected files the current solution is sufficient
(with the addition in 0.8.0 of entering a password in the Retry dialog).

One way to avoid the problems with that NZB is splitting of the NZB upfront.
(See: http://wiki.sabnzbd.org/roadmap item "Autosplit").
That feature, however is not easy to get right and will take quite some time.

I agree that the current solution is fine for passwords. I was just thinking that it could be another situation where it might be helpful to move the files off the temp drive until you can manually intervene. Regarding the splitting, is that what programs like QuickPar do? That may be a really stupid question, but I honestly have no idea what's actually happening behind the scenes with these files; I just know the end result. At first, I thought these were just fancy RAR files, but when I had to find and use QuickPar, it became obvious that these were parity checks, so quite a bit of data can be lost yet still be recoverable via calculations, which then explains the high CPU usage.

Please don't feel obligated to explain this as I suspect it could take too much of your valuable time and I may still not understand, due to the complexity, but what I'm curioius about is why SAB couldn't handle the way this NZB was structured. To a non-programmer like myself, the logic goes, "If QuickPar can do it, shouldn't SAB be able to? Or, couldn't it call QuickPar, like it does unRAR?" Again, I'm not pushing for a fix, but I'm an inherently curious person who likes to understand the "why" and "how" behind the way things work or don't work.