SABnzbd Forums

Hi Guys,

I'm having problems with post-proc scripts being executed for jobs that have 'Script = None' set.

I've got:
- A category called 'ABC' with script set to 'None'.
- An RSS feed with default Category/Script set to 'ABC'/'None'. (Used to be 'ABC'/'Default')
- Multiple regex patterns for the RSS feed, most with Script set to 'None', but a few set to 'MyScript'. (The ones set to 'None' used to be 'Default')

Unfortunately, no matter which pattern is matched, 'MyScript' is executed for it.

Let me know if you need any other information.

Version: 0.5.4
OS: CentOS 5.5 x86_64
Install-type: Python source
Skin: Default
Firewall Software: iptables
Are you using IPV6? no
Is the issue reproducible? It's happening every time for me, whether I can reproduce it on other SABnzbd install, I don't know.

Did you try a restart after you made the changes ?

E71 wrote: - Multiple regex patterns for the RSS feed, most with Script set to 'None', but a few set to 'MyScript'. (The ones set to 'None' used to be 'Default')

Remember that the first regex that is matched will be executed.
So maybe a good idea to set the NONE script ones on top

rascalli wrote: Did you try a restart after you made the changes ?

Hmm... I am not sure why that didn't occur to me. Thanks for the reminder, I'll try that and let you know next time it matches something.

rascalli wrote: Remember that the first regex that is matched will be executed.
So maybe a good idea to set the NONE script ones on top

I'm fairly sure my 'Accept' patterns match mutually exclusively, however there's a few 'Reject' patterns that are likely to match first before it gets to any 'Accept' ones.
Would their Script settings affect the final outcome?

I've now set all the 'Reject' ones to 'None' just in case.

Thanks for your help,
E71

The filters are tried from top to bottom.
The first match triggers action (either reject or accept).
The attributes of each filter are unique.
If a certain filter triggers, it will use the attributes of that filter.
However, sometimes filters are a bit too broad an one will fire too early.
You can see in the log file which filter triggered (rather cumbersome).
The next major release will show in the UI which filter was triggered for a job.

There's also a hierarchy in the attributes.
1. script of the filter, unless "Default"
2. script of the feed, unless "Default"
3. script that was set in Config->Switches

Version: 0.5.4 & 0.5.5
OS: Windows XP
Install-type: zipped binary
Skin: Default
Firewall Software: ZoneAlarm Free
Are you using IPV6? no
Is the issue reproducible? Probably, still verifying.

I think i have this same problem. Whenever my RSS feeds get downloaded, the get put in the correct (TV) category, but the script that is executed is not the script that is associated with that category. The filters all have the TV category manually set and i verified in the log that it is correctly recognized when executing the script. It is simply using the incorrect script.
I tried a clean install of sabnzbd, removing all previous settings. When i added  my filters again with the correct categories, everything seemed to work fine. All filters here were set to Default script, categories set to TV and on the categories page i had set the TV category to my script, let's call it "TV_Script". This seemed to work fine, with every download using this TV_Script as script. Then i changed the script on some filters to another script, let's call that "My_Script" and set their category to Default. Now every download from these filters seems to be using My_Script instead of TV_Script. So it seems the problem comes when you define different scripts for your filters.

When i had this problem in 0.5.4, some downloads did seem to use the correct script, but i never found out what made them different. I suspect that it had to do with their placement in my filter list. I think that when the script is being checked, according to the previously mentioned hierarchy, something goes wrong at the first step, specifically the "unless Default" part of it. I think that sabnzbd might be checking all scripts for all filters (possibly only up until the triggered filter) and if any of them is not Default, it will use that non-default script for that download.

I am not sure, but i also think that the problem described in this topic might be caused by the same thing as this problem.

I hope this helps in fixing this bug, it's pretty much the only problem i have ever had with this otherwise awesome program.

I would need to have your exact setup to find out.
The best is to email your sabnzbd.ini file to bugs at sabnzbd.org.
Don't forget to remove all passwords and add the URL of this thread.

Mail sent.

I don't quite get your problem.
First, the INI file you sent me doesn't contain any specific script settings in the RSS section.
The only script is in the TV section.
This works OK: it used the script-with-the-long-name for each NZB which gets category TV.

arucard wrote: When i had this problem in 0.5.4, some downloads did seem to use the correct script, but i never found out what made them different. I suspect that it had to do with their placement in my filter list.

Of course the order influences the script selection.
All filters are tried in order until one matches and the NZB will get script that's associated with that filter.
If the category and script of the filter are both default, the feed-level category or feed-level script will be used instead.
This just works.

I really need more details on the problem.
I'm not claiming that there isn't a problem in SABnzbd, but I cannot discover any, given your data.

Oh, I'm sorry about that. I changed the script settings back to see if that will fix it when the rss finds new downloads. That's to verify that having the script for every filter on Default does make it work correctly. The problem did occur when i had some (3 to be specific) filters set to a different script. When i set the script for these three filters to something else, it uses that script for every download from the rss feed, including the filters that still have their script set to Default.

So when a filter gets accepted, it gets downloaded as the correct category, but it uses the script from one of the other filters, specifically one of the other filters that's been changed to something non-Default. But I also noticed that this didn't ALWAYS occur, especially in 0.5.4, so i think that maybe the filters that are accepted before the filter with the non-Default script gets assessed do get the correct category-script added, but not the ones that get accepted after that filter is assessed.

I can change it back to my previous settings and send you the ini file, but the only difference is that three of the filters have a different script, which is named almost the same as the script-with-the-long-name except the last part (from "AndOr" on).

My guess on the cause of this is that somehow sabnzbd isn't not recognizing that the filter-level script for a filter is Default when a DIFFERENT filter has a custom script defined there. It then uses that custom script from that filter for other filters, possibly only filters that are accepted after the filter with the custom script is assessed by sabnzbd. So because it doesn't see that that filter-level script is on Default, it doesn't fall back to the category-level filter, which is what it's supposed to do.

I know that I've repeated the same thing a few times now, but i just hope that describing it in different ways makes it cleared. I don't think i can really explain it that well. When i said:

I suspect that it had to do with their placement in my filter list.

I meant that i suspect that the placement of that non-Default, custom script in the list of filters had something to do with which filters mistakenly used that custom script, since it didn't seem like all filters were affected.

I think that in the code where every filter gets checked successively it doesn't clear the script variable when a non-Default filter or a filter that has an actual name has been found before iterating on to the next filter. This means the name of that script gets carried on to the assessment of every filter after that. I think something like that may be happening here. I hope that clears it up a bit.

Looking at the code, you could be right.
I'll let you know when I know more.
There is indeed a bug in this area.
It will be fixed in the next minor release.
Thanks for your patience to explain it.

shypike wrote: Looking at the code, you could be right.
I'll let you know when I know more.
There is indeed a bug in this area.
It will be fixed in the next minor release.
Thanks for your patience to explain it.

No problem, I'm just glad to know that it'll be fixed in the next release. Thanks for your help with this.

Confirmed working on 0.5.6 -- Thanks guys.