SABnzbd Forums

dynup wrote:Yes, when you have installed NZBdd 1.1, than you could compress the directory to a .tar.bz2!

To install the NZBdd 1.1 deb, it would need admin rights. And that is my point: I don't like to install software-under-test with admin rights. I even don't install SABnzbd alpha / beta version with admin rights; I just unpack it in some subdirectory of my home directory.

So therefor I would like to have a NZBdd file that I can unpack as normal user into some subdirectory, and then further test it.

Can you provide that file for 1.1, just like you did for 1.0?

You don't need admin rights for installing NZBdd 1.1!

Installer for all future versions! ...but always with or without admin rights!

dynup wrote:You don't need admin rights for installing NZBdd 1.1!

Installer for all future versions! ...but always with or without admin rights!

Ah! From http://sourceforge.net/projects/nzbdd/f ... uxe%201.1/ I downloaded NZBdd-1.1-linux-installer.run, and then:

After installing and starting, I get the error message "Cannot start SABnzbd! Is it installed?".

Some more experiences:

I started NZBdd 1.1 on a Windows system. It showed the downloads on a remote server I had accessed earlier with NZBdd. That remote server has a username/password. So far so good. However, I couldn't add a .NZB; again a message about "... remote ... ". Not so handy.

However, from that moment on, I couldn't access my locally running SABnzbd anymore with my webbrowser: it was not listening on 0.0.0.0 anymore. It turned out NZBdd had filled out the FQDN of the remote host in local sabnzbd.ini. Again? I thought that was solved.
Furthermore, NZBdd had filled out the remote username/password into the local sabnzbd.ini, and so my locally running SAB suddenly wanted a password. :-(

I have the strong feeling NZBdd 1.1 is still mixing up local and remote SAB instances. More specific: I have the strong feeling NZBdd 1.1 is saving info about remote system into the local sabnzbd.ini. If so, that's not good.

Ok, any suggestions to resolve the local/remote problem?

dynup wrote:Ok, any suggestions to resolve the local/remote problem?

First, basic rule: "if remote server, do not touch the local sabnzbd.ini. Never. Not for reading, not for writing.".

And that means NZBdd needs to have its own settings file for remote servers.


I must say I like it that NZBdd reads the local sabnzbd.ini for the local server; it avoids that the user has to give the information that's also readable via sabnzbd.ini. I'm not sure how that works with multi-user systems, or system where SAB is running as a service.

Maybe NZBdd should just leave it at reading the local sabnzbd.ini (and no writing). This could be done only at the initial setup, or at each start.
After that, NZBdd could (should?) use its own settings file, with just a few parameters: URL (including port), and login and/or API-key. I guess that's enough for all functionality.

More strange stuff with NZBdd 1.1 on Windows 7:

the file ext .NZB is associated with NZBdd. Downloading a .NZB (from binsearch), results with the following entry in the SAB download queue:

http://blabla.2010.dvdrip.xvid-vomit

That is not an URL; it's the name of the .NZB file. :-(

Needless to say, this results in "URL Fetching failed; (), Try again " in the History.

So: NZBdd passes the name of the .NZB file as an URL into SABnzbd ... ?

NZBdd doesn't touch the sabnzbd.ini file, all access via api, curious! ...I'll check it! (incorrect behavior on Windows too!)