Queue stall after scheduled action "Resume" [Reproducible]

[funberry]

My ISP provides unmetered bandwidth after 2 AM, so for years I've had a Daily Schedule to Resume at 02:00. Recently I updated from I believe the 0.7 series to version 1.1.1 and starting having problems (OS X 10.8.5).

Sometimes (perhaps an incidence of 15-20%) sabnzbd fails to resume downloading at 2 AM. I see in the logs +INFO that the event is triggered, e.g.:

Code: Select all

2017-01-14 02:00:00,001::INFO::[downloader:243] Resuming

but, then the log is silent, e.g., no connections to servers are initiated.

Looking in the morning, sabnzbd appears to be unpaused. The display in the OS X menubar shows "------" on the top with "0 B/s" below. Pausing and resuming sabnzbd using the web ui appear to function, but have no effect. Setting the priority of a queued item to "Force" also has no effect. I need to quit and re-launch sabnzbd to get things going again.

I'll stress that earlier sabnzbd versions have been reliable for years on my setup and that 1.1.1 seems reliable for weeks if I don't Pause it. I've also haven't been able to reproduce this stall by manual pausing/unpausing.

Please let me know if there's any more information I can provide that might help. I see that 1.2.0 is out and I will try this new version.

[safihre]

Will put this on the list..

[funberry]

I'll confirm the bug is still present in 1.2.0. Resume worked for 5 or so nights, then it stalled again.

BUT, I accidentally discovered that pushing an NZB to the queue (using the NZB Key) will get sabnzbd going again without having to quit/relaunch:

Code: Select all

2017-01-22 02:00:00,000::INFO::[downloader:255] Resuming
2017-01-22 08:42:09,460::INFO::[__init__:552] Fetching https://####.###/getnzb/<HASH>29fa8a4f1b3cda0&i=14319&r=<HASH>76bcea9
2017-01-22 08:42:09,485::INFO::[nzbqueue:258] Saving queue
2017-01-22 08:42:09,486::INFO::[__init__:970] Saving data for queue10.sab in /Volumes/Macintosh HD/Users/<USERNAME>/Library/Application Support/SABnzbd/admin/queue10.sab
2017-01-22 08:42:09,488::INFO::[urlgrabber:110] Grabbing URL https://####.###/getnzb/<HASH>29fa8a4f1b3cda0&i=14319&r=<HASH>76bcea9
2017-01-22 08:42:10,028::INFO::[downloader:477] 3@news2.#######.com:119: Initiating connection
.
.
.

[safihre]

So you say it works for a few days, and then stops working?
In that time, Sab is never shutdown or restarted?
After a restart, it works again or never again?
Could you maybe try if it helps to put a daily scheduled restart somewhere?

[funberry]

So you say it works for a few days, and then stops working?

no, I said sabnzbd fails to resume downloading with an incidence of about 20%. The stall has happened on day 1, but usually not.

In that time, Sab is never shutdown or restarted?

Most of the time the Resume action works for a few days. The stall happens with items that have been added to the queue since sabnzbd was launched. It would probably happen with jobs left over from a previous session too, but I don't recall ever doing that.

After a restart, it works again or never again?

Like I said, quitting and re-launching sabnzbd will get the queue going again.

Could you maybe try if it helps to put a daily scheduled restart somewhere?

I'm not too concerned with working around the problem, I'm interested in helping reproduce the bug.

Based on my recent observation that pushing a NZB un-stalls sabnzbd, my working guess is that the stall is not actually random, but may be related to whether items are added to the queue before or after pausing, whether or not there are partial downloads, and/or some combination. It seems like something isn't getting prepared/cleaned up internally, and whatever routines are triggered by pushing an NZB corrects that. I will post another update if I can figure out how to make this more reproducible.

Edit: I've added Restart action at 01:55 before my usually 02:00 Resume, and will see if I can still get stall.

[funberry]

I haven't observed any stalls while testing a scheduled 'Restart' action just prior to the scheduled 'Resume' action. I expected this result because the stall has been correctable by restarting sabnzbd.

[funberry]

- create a scheduled action "Resume" at your target time, say 10 minutes from now for the purpose of testing this bug
- pause sabnzbd
- add 2 items to the queue, BUT ensure the first item is small enough to finish downloading before the scheduled action is triggered
- set the priority of the first item in the queue to "Force"

The first item will download, the scheduled action will trigger, but recent versions of sabnzbd will NOT resume. Downloads are stalled until sabnzbd is restarted or a new NZB is pushed using the NZB Key.