Completed Downloads folder resetting to default

[distantstorm]

Not really sure if this qualifies as a bug but I have my completed downloads folder set to an external docked eSATA drive. Occasionally I have to switch the drive in the dock to retrieve a file, perform a backup or whatever. Sabnzbd seems to see that the drive is not there and switches the completed downloads to the default /downloads/complete. This is great because it doesn't throw a wobbly or anything but when the drive is reattached the completed folder stays at the default  /downloads/complete - even after a shutdown and restart. It would be great if my choice of completed folder was remembered and it switched back to it when the drive was available again. I like SABnzbd+ running at startup and don't really want to change this if I can help it.

Version: 0.5.3 Final
OS: OSX Snow Leopard 10.6.4
Install-type: OSx .app
Skin (if applicable): Default
Firewall Software: None
Are you using IPV6? No
Is the issue reproducible? Yes

[fanniecat]

In windows, I made the sabnzbd configuration file read only to prevent the program from changing to the default save paths.  That works OK for me (it just pauses the download and doesn't require me to re-enter the paths in the configuration, which bugged me much more than pausing the downloads does).

I would prefer if I could set up a secondary save path instead in case the preferred drive is afk (or full).  It probably is possible for me to change the default paths by messing with the code myself, but I haven't been very motivated to mess with that (so I can understand if the developer doesn't feel very motivated to mess with it either).  Still, it's a nice idea, especially if it could be implemented easily.

[guitarboy]

Seems odd that the program will reset the folders.  Anyone who goes to the trouble of overriding the defaults probably knows what they're doing.  Nice trick to set the config file to read only, but that shouldn't be necessary.

[RKM]

I agree with all of you..  This happens to me *all* of the time and it has me pulling my hair out...

This should be a very simple fix because you're simply removing a "feature" that probably was not intended and certainly is annoying because it deletes information that the user has configured.

For example, I have SABNZBD+ downloading to "media".  If for any reason, SABNZBD+ has a problem with that path, the "Completed Download Folder" will then get reset to the default.

It's fine to *save to* the default location if there is an error, but the user's intended setting should not get deleted.  Please, remove this current behavior -- save to the default/backup location (or better yet, just leave in the temp location) -- but PLEASE do not delete our settings.

Thank you in advance!

[shypike]

Filed in the bugtracker for the next release.
https://bugs.launchpad.net/sabnzbd/+bug/672912

[shypike]

It's not going to make into the next minor release. It's too complex for such a release.
Instead 0.6.0 will add three improvements:
1. Delayed creation of any final folder until it is required
2. When the final folder cannot be created, post processing will fail. But you can retry later (from History).
3. On OSX, SABnzbd will not create new folders in /Volumes, but instead assume that drive was not mounted and thus revert to 2

[RKM]

shypike-
Thank you for adding it to this list, this is truly great news.

Just for the benefit of others passing by, the suggestion of setting the config file to read only, does not work.

At present I have not found any workaround.

[RKM]

I just wanted to mention that in the bugtracker this is noted as affecting one person, but 4 people have commented on it in the thread.  I noticed it's not yet "assigned", so I just wanted to make sure it's still on-track for v6.

I've tried setting permissions on the config file, but nothing stops SABNZBD+ from rewriting the config with the default path, if the NAS is reboot.  Even if just for a second.

Thank you in advance!

[shypike]

It's already implemented in 0.6.0 source code.
I'm not sure in which bugtracker you are looking, but we track bugs here: https://launchpad.net/sabnzbd
The Assembla.com tracker is obsolete.