SABNZB 3.2.1-48 on Synology not downloading

[elove7300]

I checked today and the problem is back. SABNZB stopped downloading and i have 2 in the que just turned on debugging here's the url

https://pastebin.com/B3M8UW3e

[sander]

Your sabnzbd.log shows your SABnzbd is restarting again and again:

Code: Select all

2021-07-29 17:16:26,830::INFO::[__init__:1004] Restarting because of crashed downloader
2021-07-29 17:17:03,652::INFO::[__init__:1004] Restarting because of crashed downloader
2021-07-29 17:17:40,490::INFO::[__init__:1004] Restarting because of crashed downloader
2021-07-29 17:18:17,376::INFO::[__init__:1004] Restarting because of crashed downloader
2021-07-29 17:19:09,234::INFO::[__init__:1004] Restarting because of crashed downloader
2021-07-29 17:19:46,138::INFO::[__init__:1004] Restarting because of crashed downloader
2021-07-29 17:20:23,015::INFO::[__init__:1004] Restarting because of crashed downloader

The source code

Code: Select all

    if not sabnzbd.Downloader.is_alive():
        logging.info("Restarting because of crashed downloader")

So sabnzbd.Downloader.is_alive() is False. I don't know why: because Download crashed (because there is something weird in your download queue), or because it couldn't start at all..

The best thing for debugging would be to have an empty download queue. So empty the queue, and do not add anything to it (neither via Radarr/3.0.2.4552). As SAB is crashing, I would say
* empty queue (but that is lower level stuff, so difficult), stop Radarr
* the brute-force way to do it is: uninstall SABnzbd, install SABnzbd,, make sure you get the wizard and nothing is in the queue.

[elove7300]

Downloaded it thus morning then configured it about 10 minutes ago 3.50pm EST. Sonar gave a bunch of error so I stopped it as well as rada and the que is empty. It already started the restarting. here is the link for the log files.

https://pastebin.com/RXxxq79P

[sander]

the que is empty

, and still "crashed downloader". That is bad.

I see two other things in your sabnzbd.log
* you've set your login again, right?
* you've set a bandwidth limit, right?

What happens when you remove that? I think "downloader" and bandwidth limit interact with eachother.

Normally I would advice to try out another (older) version of SABnzbd, but I don't know how you can do that on Synology

Code: Select all

2021-07-30 15:02:43,366::INFO::[__init__:1004] Restarting because of crashed downloader
2021-07-30 15:03:20,250::INFO::[__init__:1004] Restarting because of crashed downloader

[elove7300]

maximum limit in blank and percentage of line speed is 100. I had the username password set and had it not set still restarts. I went through permission and sonar radar and sabnzb all have sc-medial and sc-download permission

[elove7300]

I took your advice Sander and downloaded and installed a fresh copy of an earlier version of SABNZB. I went to the syno-community found the previous releases and downloaded version 3.2.0-47 for "6.1 Avoton" which is what my architecture was per github for an 1815+. That was maybe 21 hours ago and no crashing no errors and last download was maybe 2 hours ago. I did add a username password but I left the maximum line speed blank, percentage of line speed is 100% and I didn't input a https port. Waiting until tomorrow before I call it fixed.

[sander]

And? How is 3.2.0-47 behaving?

[elove7300]

It's been fine no crashing no problems downloading and no errors. I just triggered a manual downloaded right now to make sure and everything is behaving as it should!

[sander]

So: on your Synology:

3.2.0-47 works for you
3.2.1-48 gives you "Restarting because of crashed downloader"

In https://github.com/sabnzbd/sabnzbd/releases/tag/3.2.1 I don't see anything that rings a bell for me.

Furthermore: SAB 3.2.1 runs on thousands of other Synology systems without problems. So something special with your system or setup.

My advice to you:
Stay on 3.2.0-47
As soon as there is a newer-than-3.2.1-48 (so 3.3.x or 3.4.x): install that, and find out how it behaves, and report back here.

[elove7300]

That sounds like a plan. I will do that. Thank you!

[elove7300]

So I just upgraded from 3.2.0-47 thinking there was a new version but apparently 3.3 but apparently it's 3.2.1-48 and so far has worked for the day. I'm still waiting a couple more days to see if it stays working

[meimeiriver]

i switched to glitter and saw an error "a few seconds ago Cannot change permissions of /volume1/Downloads/incomplete"

That is your problem: no writing access to that directory. Solve that. Or choose another directory that works. I can't help you with that; not a SABnzbd problem, and I don't use synology myself.

A bit of a sabnzbd problem too. I think sabnzbd, at some point, changed how it's run under which user in UNIX. If an old incomplete/ folder exist, new version might have this permission issue. Solution is to simple remove the folder, save the config, and sabnzbd will have created it itself, with proper permissions.

[sander]

I think sabnzbd, at some point, changed how it's run under which user in UNIX.

No, SABnzbd did not. SAB is running on all kinds unixes (Linux, MacOS), and no problem
Maybe Synology did change something, but not SAB. And SAB 3.2.1 is running correctly on a lot of Synologies, so not a generic problem.

If an old incomplete/ folder exist, new version might have this permission issue. Solution is to simple remove the folder, save the config, and sabnzbd will have created it itself, with proper permissions.

Hopefully that works for the OP. That would be nice

Triggered by your remark, I verified something:
1. Start a download. Halfway stop it (so incomplete is filled)
2. Make the incomplete directory and its subdirectory not-writable, and start SABnzbd again.
3. SAB nicely says " Disk error on creating file" and stops downloading. So not a "crashed downloader"

So: SAB is behaving correctly, and does not yield "crashed downloader" (which the OP has). That is good news. But a pity for the fault analysis of the OP

[meimeiriver]

I think sabnzbd, at some point, changed how it's run under which user in UNIX.

No, SABnzbd did not. SAB is running on all kinds unixes (Linux, MacOS), and no problem
Maybe Synology did change something, but not SAB. And SAB 3.2.1 is running correctly on a lot of Synologies, so not a generic problem.

If an old incomplete/ folder exist, new version might have this permission issue. Solution is to simple remove the folder, save the config, and sabnzbd will have created it itself, with proper permissions.

Hopefully that works for the OP. That would be nice

Triggered by your remark, I verified something:
1. Start a download. Halfway stop it (so incomplete is filled)
2. Make the incomplete directory and its subdirectory not-writable, and start SABnzbd again.
3. SAB nicely says " Disk error on creating file" and stops downloading. So not a "crashed downloader"

So: SAB is behaving correctly, and does not yield "crashed downloader" (which the OP has). That is good news. But a pity for the fault analysis of the OP

Yes, it was Synology who decided to change the way SAB should run. See, for instance, viewtopic.php?t=21796. So, I should have said 'SAB in Synology'. They also forced SAB to run under the new Default Base Folder: /volume1/@appstore/sabnzbd/var/admin now. That is what tripped me up, briefly, when I was using the config of the previous version, with hardcoded /volume1/Downloads/incomplete folder in it. So, just deleting old incomplete folder did it (as it gets recreated with proper permissions). Cleanest would have been to just use the new Base Folder paths, but I had networked drives set to the completed folder and such, so I kept the old folder structure for that.

But yeah, SAB never crashes; and it shouldn't. It could segfault, maybe, but that's usually the result of a miscompilation. None of that has ever happened to me, though. SAB just nicely immediately said it couldn't access the incomplete folder. At any rate, even a blunt chmod 777 would solve it.

[sander]

But yeah, SAB never crashes; and it shouldn't.

IMHO the "crashed downloader" is a mini-crash. Or, to be more technically accurate: SABnzbd periodically checks if all threads are still running. In the OP's case, SABnzbd finds the thread Downloader is not running, and then throws the message.

It could segfault, maybe, but that's usually the result of a miscompilation.

segfaults seldomly happen with SABnzbd, and are outside SABnzbd's control: Faulty hardware, faulty libraries, limited memory. Not a programming error within SABnzbd.