SABnzbd Forums

This issue is an intermittent one that I've encountered time to time. I have various download categories with different post-processing tasks (but no user scripts); some only repair (R) while others will unpack and delete (D) the original archive files. When I add nzb's via the webui (smpl skin) and designate a category, the post processing task is incorrect when the files are in the queue even though the correct category is assigned.

A more concrete example:
I have configured the "movies" category to unpack and delete files after download. I add an nzb and assign it to the movies categories via the webui mainpage. The nzb is placed in the queue under the proper movies category, however, post-processing shows that the the files will only be repaired (R). I have to select another category (either "none" or some other one) and then switch back to the movies categories so that the correct post-processing task (D) is now shown.

It's a minor inconvenience, but I think that sabnzbd may be falling back to my default post-processing setting, which is to repair, despite whatever post-processing settings are defined by the category itself.

You will need to supply logging taken just after such an error occurred (preferably debug level).
You can send info to bugs at sabnzbd.org.

I cannot confirm the problem.

I've just sent an email to you with a debug log.

I just realized something: in the home page for the sabnzbd ui (smpl skin), where one can add nzb's via an url or an uploaded file, there are three columns of drop-down menus--category, post-processing (none, +R, +U, +D), and user scripts (if any). When I add files, I usually assign them to a category via the drop-down menu and leave the other parameters "default." It would seem intuitive that assigning a category to an nzb set should also set the appropriate post-processing mode, any user scripts, and any non-default download folders that have already been defined by that category. However, it appears that the post-processing mode and user-script options in drop-down menus will actually override the settings that are configured for the given category. Thus, when I only assign the category to a set of files and leave the post-processing modes (my default is +R) and user script (my default is none) at "default," the files are added to the queue with the given category but default post-processing mode and user scripts; not the predefined ones set by the category itself. Now, if nzb's are added via placing files in the watched folders (and perhaps via RSS as well, but I have not tested it), the category along with its appropriate predefined post-processing mode and user script is properly assigned to the nzb task.

I'm not sure if this behavior for categories was intended in the design process, but I think setting the category for a task should assign the predefined modes and override any other settings.

The design is:
For the main page and RSS feeds:
When you set the category and leave the other fields "Default", the options defined for that category are used.
If you set explicit parameters (like a different script), those will have priority over the category script.

The watched folder is different, it can only have a category (by using a prefix or a sub-folder).
So the PP and the script can only come from the category (if any).

There is an error in SABnzbd 0.4.4 which messes up this method for jobs coming in through RSS feeds.
This will be fixed in the coming 0.4.5 release.

I don't set explicit parameters for PP or scripts, just the category. So it would seem that there is a bug with how PP and scripts are applied in the main page if there is a category assigned (ie. they're not using those defined by the category and in fact using those on the drop-down, which, if left alone, is "default.")

...OK, looking forward to a fix.

Indeed, the main page suffers from the same problem.
Will be solved in 0.4.5.

i think this issue is back in 0.4.7: nzb's added via the homepage are correctly assigned their category, but the post-processing defaults to the default setting.

I cannot confirm your complaint.
When a category has a PP that's different from the default (as set in Config->Switches), the category PP is used.

Can you describe your exact situation and problem?

OK, I think i can clarify a bit as I now realize that it is not exactly the same issue as before. I'm manually adding NZB's via the homepage, but I don't manually assign the nzb to a category via the drop-down menu option. Under Config>Categories, I have defined several newsgroups (alt.binaries...) that will trigger/assign a category to an nzb. Thus, the newly added nzb is assigned the appropriate category as defined by the group, however the post-processing options are not correct as defined in the Config>Categories, but instead have the default settings.

This differs slightly from the original problem in October, where I would MANUALLY assign a category to the new nzb and the post-processing were not correctly assigned. That issue had been addressed. Here the nzb is automatically and correctly assigned a category, as defined by the various triggering newsgroups, but the post-processing options applied are not correct.

OK, I tested the other scenario (manual picking of category).
So if I understand correctly, the group to category conversion doesn't work properly?
I will look into this further.

After checking the code, I'm afraid I have to disappoint you.
Currently groups are not supported when files come in  through the main page or the Watched Folder.
It only works when jobs come in through the newzbin interface (report numbers or an RSS feed on newzbin).

I cannot promise we will solve it in a new 0.4.x release, because it's too small a problem to create a release for.
I will have look if it can be solved it in 0.5.0.

The reason we dropped group support one day is that the code just became too complex to maintain.
(E.g. what do we do when a user enables both categories and group-based folders?)
Later we tried to more or less restore group support by supporting it in the categories (but badly as you have seen).
Too be quite honest, we would rather drop it completely.

I had a closer look at this problem.
There's a small problem with one of the libraries we use (easy to fix).
I have one question for you:
Did you enter a list of groupnames or just a single name?
My testing shows that a list of group names doesn't work properly.

This is OK This fails: This will be fixed for a later 0.4.x release.

sorry I have not responded (I'm subscribed to this thread, but didn't receive an email updating me)....
I usually use the groups to assign categories for nzb's that are fed via RSS feeds, but lately have been adding some nzbs manually as well, which is when I first noticed the issue. Presently, the particular category I have been using only has one group in it. I do have others categories that consist of a list of groups as well. I understand it's a small issue so it's not such a big deal (I'll just have to remember to double check PP options in the queue), but I'm glad that you're aware of it and hopefully there can be some resolution in the future.

Great work!

We are working on an unrelated problem in the OSX release.
So maybe a 0.4.8 release will be done soon anyway.
I'll keep you informed and may ask you to test.