Do you experience problems during downloading?
Check your connection in Status and Interface settings window.
Use Test Server in Config > Servers.
We will probably ask you to do a test using only basic settings.
Do you experience problems during repair or unpacking?
Enable +Debug logging in the Status and Interface settings window and share the relevant parts of the log here using [ code ] sections.
Version: 0.7.2
OS: OS X 10.5.8
Install-type: DMG
Skin (if applicable): (Ex: Default, Plush, Smpl)
Firewall Software: OS X firewall
Are you using IPV6? No
Is the issue reproducible? Yes
Exits immediately on startup. Version 0.6.x did not have this problem.
Confirmed using application from folder "OS X 10.5 and Below"
Trashing the "SABnzbd" folder from ~/Library/Application Support/ results in SABnzdb running the setup wizard when started. However, the application quits after the wizard is complete and immediately quits when attempting to start it from then on.
Returned to version 0.6.15 and application works OK.
We try to support PowerPC but have no way too check whether it works.
The pre-SnowLeopard part is still generated in the same way as for 0.6.15 and earlier.
But like I said, we cannot actually test it on PowerPC hardware.
The 10.5 version does run fine on Intel hardware.
The only work-around that might work, is disabling the top menu icon.
For that you would need to edit the ~/Library/Application Support/SABnzbd/sabnzbd.ini file
Find the osx_speed and osx_menu and set both to 0.
After that, start up SABnzbd.
I don't think the logging you show is relevant.
Can you look in this file?
/Users/user/Library/Application Support/SABnzbd/logs/sabnzbd.log
Where user is your login name.
Otherwise open a Terminal windows (Applications->Utilities) and type:
/Applications/SABnzbd.app/Contents/MacOS/SABnzbd --console --server 127.0.0.1:8080 --no_ipv6
Hi there, first post - I'm just setting up a new G4 (PPC) server, running 10.5.8 and I have the same error in the console log - and this in the sabnzbd.log (seems like the most relevant bit, I can post more - but it just looks like failed retries).
Update: I trashed the SABnzbd directory in App Support so that the wizard started up again - I stuck to the defaults and it completed, restarted and stayed up - seems fine. Recommend as a first step for anyone - and I'll see if I can nail down what option causes the issue.
I have also been able to get 0.7.2 running since my last post. The only suggestion of what I did differently was NOT setting up LAN access in the wizard. I then manually changed SABnzbd Host from "localhost" to the IP address of the server and restarted.
I finally sat down and decided to sort this out on my system. If the listening address is set to 0.0.0.0 it will crash out right after startup. If the address is set to "localhost" or the IP address of your network adapter everything works as expected.
It seems to me that this won't affect too many people, as most people only have one network adapter which they want to listen on, but it does seem to me that without being able to use 0.0.0.0 there are 2 scenarios which will not be supported. The first most obvious would be that it won't listen on multiple adapters, if you have them set up. The other would be that you have to use a static IP address for your sabnzbd system, this would seem normal to most, but with Bonjour it isn't absolutely necessary in a Mac environment.
0.6.x had no problem with the 0.0.0.0 setup. I have not yet attempted using the sources instead off the app. Although I bet I will have to go that route as PPC precompiled support going forward is probably going to get slimmer.
My system:
xServe G5, OSX 10.5.8, one network adapter used, the other unplugged.
My thanks to everyone who put in the time earlier in this thread. I could not figure it out and just kept reverting back to 0.6.x every time I tried the new 0.7.x release.
Multiple network adapters are not rare in modern hardware.
Most laptops (and all newer desktop Macs) have wired and WiFi.
It's not so much having two adapters, but more that OSX's DNS sometimes messes up its localhost definition.
Hardcoding "127.0.0.1 localhost" in /etc/hosts can work wonders for this issue.
