SABnzbd Forums

Great release, thanks a ton!

I'm using sabnzbd as a Windows service. I have found that in addition to the restrictions listed in the installation notes (http://wiki.sabnzbd.org/sabnzbd-as-a-windows-service), all folder locations must be fully specified and not be relative to the logged on user.

Not quite.
You must use the -f parameter.
The folder part of that path is the root for all relative folders.
You can see this in Config->Folder.

shypike wrote: Not quite.
You must use the -f parameter.
The folder part of that path is the root for all relative folders.
You can see this in Config->Folder.

I am using the -f parameter. My sabnzbd.ini was found and used just fine. However, my script folder was not found until I entered it as fully qualified path. Without that, no scripts. With it, scripts. I assumed that would hold for the other folders, most of which I had previously configured with full qualified paths already, but didn't get a chance to check.

On the other hand, the "admin" folder in "LocalSettings\AppData" was found correctly, a fact which I didn't realize until after I posted here.

minimeh wrote:

shypike wrote: Not quite.
You must use the -f parameter.
The folder part of that path is the root for all relative folders.
You can see this in Config->Folder.

I am using the -f parameter. My sabnzbd.ini was found and used just fine. However, my script folder was not found until I entered it as fully qualified path. Without that, no scripts. With it, scripts. I assumed that would hold for the other folders, most of which I had previously configured with full qualified paths already, but didn't get a chance to check.

On the other hand, the "admin" folder in "LocalSettings\AppData" was found correctly, a fact which I didn't realize until after I posted here.

I see the problem. This is an upgrade issue in Windows.

In version 0.5 there were "User Folders" and "System Folders". User folders were based on the user's document folder, while system folders were based on the users AppData\Local folder. So where original folders may be lost during the upgrade from 0.5 to 0.6 is in the user folders, namely "Temporary Download Folder", "Completed Download Folder", "Watched Folder", "Post-Processing Scripts Folder", and "Email Templates Folder". In my setup, only "Watched Folder" and "Post-Processing Scripts Folder" had been left as relative folder names, so they were lost until I specified a completely qualified path name for them because the sabnzb.ini path that I passed in as the -f parameter referred to the original location, in the system folder.

I'm glad you understand it now.
But it's not an upgrade error.
The -f parameter has been in for years and has always had this functionality.
It's normally used in combination with the -d (daemon) mode which is primarily interesting for Linux users.

shypike wrote: But it's not an upgrade error.
The -f parameter has been in for years and has always had this functionality.
It's normally used in combination with the -d (daemon) mode which is primarily interesting for Linux users.

Yeah, "upgrade error" might be the wrong term. Perhaps "migration issue for Windows installation" would be more appropriate.

The point is, in a standard Windows desktop installation of sabnzbd, the various folders are divided into two branches: user's local application data and user's documents. When migrating an existent Windows desktop installation to the service model, the "user's" context is lost. That loss is compensated by using the "-f" parameter to the configuration file. Unfortunately, that orphans any resources that were previously in the user's documents branch. Any paths that are named in the configuration file that indirectly reference the user's documents branch must, when using the "-f" parameter, be fully qualified. The other option is to merge the documents branch and the applications branch into one location so that all indirect path references may resolve off of the "-f" parameter path.

It seems that a mention of that for the benefit of Windows users who are going to migrate an existing installation to the newly implemented Windows service functionality would be useful.