Just adding my voice to the mix. I also have noticed the "stuck at unpacking" issue with this docker container. I've just always manually restarted, which would fix the issue. For now, I've gone ahead and set up an hourly cron job to restart the docker, but I'll keep an eye on this thread to see if any more developments occur!

So in the last week NZBGet which has been flawless just shit the bed. The page wont load anymore:

 

2019-07-17 14:29:05,710 INFO gave up: nzbget entered FATAL state, too many start retries too quickly

 

So I wiped it off the face of my server and USB key (appdata) waited a couple days and rebooted a couple times (family got in the way of troubleshooting). So I just reloaded it and it launched as per normal and I was setting up all my settings and reloaded NZBGet only for it to do the same thing? Did they change something recently to break your docker BinHex?

 

Created by...
___. .__ .__
\_ |__ |__| ____ | |__ ____ ___ ___
| __ \| |/ \| | \_/ __ \\ \/ /
| \_\ \ | | \ Y \ ___/ > <
|___ /__|___| /___| /\___ >__/\_ \
\/ \/ \/ \/ \/
https://hub.docker.com/u/binhex/

2019-07-17 14:23:07.167944 [info] System information Linux 6a9b07e92b8c 4.19.56-Unraid #1 SMP Tue Jun 25 10:19:34 PDT 2019 x86_64 GNU/Linux
2019-07-17 14:23:07.250336 [info] PUID defined as '99'
2019-07-17 14:23:07.835115 [info] PGID defined as '100'
2019-07-17 14:23:08.669714 [info] UMASK defined as '000'
2019-07-17 14:23:08.694079 [info] Setting permissions recursively on volume mappings...
2019-07-17 14:23:09.182446 [info] Starting Supervisor...
2019-07-17 14:23:10,250 INFO Included extra file "/etc/supervisor/conf.d/nzbget.conf" during parsing
2019-07-17 14:23:10,250 INFO Set uid to user 0 succeeded
2019-07-17 14:23:10,254 INFO supervisord started with pid 6
2019-07-17 14:23:11,256 INFO spawned: 'nzbget' with pid 48
2019-07-17 14:23:11,257 INFO reaped unknown pid 7
2019-07-17 14:23:11,263 DEBG 'nzbget' stdout output:
[info] NZBGet configuration does not exist, copying default configuration file to /config/...

2019-07-17 14:23:11,271 DEBG 'nzbget' stdout output:
[info] Patching NZBGet config file for WebDir and ConfigTemplate locations...

2019-07-17 14:23:12,272 INFO success: nzbget entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2019-07-17 14:28:59,609 DEBG 'nzbget' stderr output:
/home/nobody/start.sh: line 26: 53 Segmentation fault /usr/local/bin/nzbget/nzbget -c /config/nzbget.conf -s 1>&-

2019-07-17 14:28:59,609 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22513970354152 for <Subprocess at 22513970354224 with name nzbget in state RUNNING> (stdout)>
2019-07-17 14:28:59,610 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22513970354440 for <Subprocess at 22513970354224 with name nzbget in state RUNNING> (stderr)>
2019-07-17 14:28:59,610 INFO exited: nzbget (exit status 139; not expected)
2019-07-17 14:28:59,610 DEBG received SIGCLD indicating a child quit
2019-07-17 14:28:59,614 INFO spawned: 'nzbget' with pid 90
2019-07-17 14:28:59,621 DEBG 'nzbget' stdout output:
[info] NZBGet configuration file exists
[info] Patching NZBGet config file for WebDir and ConfigTemplate locations...

2019-07-17 14:28:59,634 DEBG 'nzbget' stderr output:
/home/nobody/start.sh: line 26: 93 Segmentation fault /usr/local/bin/nzbget/nzbget -c /config/nzbget.conf -s 1>&-

2019-07-17 14:28:59,635 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22513987597952 for <Subprocess at 22513970354224 with name nzbget in state STARTING> (stdout)>
2019-07-17 14:28:59,635 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22513970371040 for <Subprocess at 22513970354224 with name nzbget in state STARTING> (stderr)>
2019-07-17 14:28:59,635 INFO exited: nzbget (exit status 139; not expected)
2019-07-17 14:28:59,635 DEBG received SIGCLD indicating a child quit
2019-07-17 14:29:00,638 INFO spawned: 'nzbget' with pid 102
2019-07-17 14:29:00,646 DEBG 'nzbget' stdout output:
[info] NZBGet configuration file exists
[info] Patching NZBGet config file for WebDir and ConfigTemplate locations...

2019-07-17 14:29:00,660 DEBG 'nzbget' stderr output:
/home/nobody/start.sh: line 26: 105 Segmentation fault /usr/local/bin/nzbget/nzbget -c /config/nzbget.conf -s 1>&-

2019-07-17 14:29:00,660 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22513987597952 for <Subprocess at 22513970354224 with name nzbget in state STARTING> (stdout)>
2019-07-17 14:29:00,660 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22513970371616 for <Subprocess at 22513970354224 with name nzbget in state STARTING> (stderr)>
2019-07-17 14:29:00,660 INFO exited: nzbget (exit status 139; not expected)
2019-07-17 14:29:00,660 DEBG received SIGCLD indicating a child quit
2019-07-17 14:29:02,665 INFO spawned: 'nzbget' with pid 114
2019-07-17 14:29:02,672 DEBG 'nzbget' stdout output:
[info] NZBGet configuration file exists
[info] Patching NZBGet config file for WebDir and ConfigTemplate locations...

2019-07-17 14:29:02,684 DEBG 'nzbget' stderr output:
/home/nobody/start.sh: line 26: 117 Segmentation fault /usr/local/bin/nzbget/nzbget -c /config/nzbget.conf -s 1>&-

2019-07-17 14:29:02,684 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22513987597952 for <Subprocess at 22513970354224 with name nzbget in state STARTING> (stdout)>
2019-07-17 14:29:02,684 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22513970370464 for <Subprocess at 22513970354224 with name nzbget in state STARTING> (stderr)>
2019-07-17 14:29:02,685 INFO exited: nzbget (exit status 139; not expected)
2019-07-17 14:29:02,685 DEBG received SIGCLD indicating a child quit
2019-07-17 14:29:05,690 INFO spawned: 'nzbget' with pid 126
2019-07-17 14:29:05,696 DEBG 'nzbget' stdout output:
[info] NZBGet configuration file exists
[info] Patching NZBGet config file for WebDir and ConfigTemplate locations...

2019-07-17 14:29:05,709 DEBG 'nzbget' stderr output:
/home/nobody/start.sh: line 26: 129 Segmentation fault /usr/local/bin/nzbget/nzbget -c /config/nzbget.conf -s 1>&-

2019-07-17 14:29:05,710 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22513987597952 for <Subprocess at 22513970354224 with name nzbget in state STARTING> (stdout)>
2019-07-17 14:29:05,710 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22513970369456 for <Subprocess at 22513970354224 with name nzbget in state STARTING> (stderr)>
2019-07-17 14:29:05,710 INFO exited: nzbget (exit status 139; not expected)
2019-07-17 14:29:05,710 DEBG received SIGCLD indicating a child quit
2019-07-17 14:29:05,710 INFO gave up: nzbget entered FATAL state, too many start retries too quickly

So in the last week NZBGet which has been flawless just shit the bed. The page wont load anymore:
 
2019-07-17 14:29:05,710 INFO gave up: nzbget entered FATAL state, too many start retries too quickly
 
So I wiped it off the face of my server and USB key (appdata) waited a couple days and rebooted a couple times (family got in the way of troubleshooting). So I just reloaded it and it launched as per normal and I was setting up all my settings and reloaded NZBGet only for it to do the same thing? Did they change something recently to break your docker BinHex?
 
Created by...
___. .__ .__
\_ |__ |__| ____ | |__ ____ ___ ___
| __ \| |/ \| | \_/ __ \\ \/ /
| \_\ \ | | \ Y \ ___/ > |___ /__|___| /___| /\___ >__/\_ \
\/ \/ \/ \/ \/
https://hub.docker.com/u/binhex/

2019-07-17 14:23:07.167944 [info] System information Linux 6a9b07e92b8c 4.19.56-Unraid #1 SMP Tue Jun 25 10:19:34 PDT 2019 x86_64 GNU/Linux
2019-07-17 14:23:07.250336 [info] PUID defined as '99'
2019-07-17 14:23:07.835115 [info] PGID defined as '100'
2019-07-17 14:23:08.669714 [info] UMASK defined as '000'
2019-07-17 14:23:08.694079 [info] Setting permissions recursively on volume mappings...
2019-07-17 14:23:09.182446 [info] Starting Supervisor...
2019-07-17 14:23:10,250 INFO Included extra file "/etc/supervisor/conf.d/nzbget.conf" during parsing
2019-07-17 14:23:10,250 INFO Set uid to user 0 succeeded
2019-07-17 14:23:10,254 INFO supervisord started with pid 6
2019-07-17 14:23:11,256 INFO spawned: 'nzbget' with pid 48
2019-07-17 14:23:11,257 INFO reaped unknown pid 7
2019-07-17 14:23:11,263 DEBG 'nzbget' stdout output:
[info] NZBGet configuration does not exist, copying default configuration file to /config/...

2019-07-17 14:23:11,271 DEBG 'nzbget' stdout output:
[info] Patching NZBGet config file for WebDir and ConfigTemplate locations...

2019-07-17 14:23:12,272 INFO success: nzbget entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2019-07-17 14:28:59,609 DEBG 'nzbget' stderr output:
/home/nobody/start.sh: line 26: 53 Segmentation fault /usr/local/bin/nzbget/nzbget -c /config/nzbget.conf -s 1>&-

2019-07-17 14:28:59,609 DEBG fd 8 closed, stopped monitoring (stdout)>
2019-07-17 14:28:59,610 DEBG fd 10 closed, stopped monitoring (stderr)>
2019-07-17 14:28:59,610 INFO exited: nzbget (exit status 139; not expected)
2019-07-17 14:28:59,610 DEBG received SIGCLD indicating a child quit
2019-07-17 14:28:59,614 INFO spawned: 'nzbget' with pid 90
2019-07-17 14:28:59,621 DEBG 'nzbget' stdout output:
[info] NZBGet configuration file exists
[info] Patching NZBGet config file for WebDir and ConfigTemplate locations...

2019-07-17 14:28:59,634 DEBG 'nzbget' stderr output:
/home/nobody/start.sh: line 26: 93 Segmentation fault /usr/local/bin/nzbget/nzbget -c /config/nzbget.conf -s 1>&-

2019-07-17 14:28:59,635 DEBG fd 8 closed, stopped monitoring (stdout)>
2019-07-17 14:28:59,635 DEBG fd 10 closed, stopped monitoring (stderr)>
2019-07-17 14:28:59,635 INFO exited: nzbget (exit status 139; not expected)
2019-07-17 14:28:59,635 DEBG received SIGCLD indicating a child quit
2019-07-17 14:29:00,638 INFO spawned: 'nzbget' with pid 102
2019-07-17 14:29:00,646 DEBG 'nzbget' stdout output:
[info] NZBGet configuration file exists
[info] Patching NZBGet config file for WebDir and ConfigTemplate locations...

2019-07-17 14:29:00,660 DEBG 'nzbget' stderr output:
/home/nobody/start.sh: line 26: 105 Segmentation fault /usr/local/bin/nzbget/nzbget -c /config/nzbget.conf -s 1>&-

2019-07-17 14:29:00,660 DEBG fd 8 closed, stopped monitoring (stdout)>
2019-07-17 14:29:00,660 DEBG fd 10 closed, stopped monitoring (stderr)>
2019-07-17 14:29:00,660 INFO exited: nzbget (exit status 139; not expected)
2019-07-17 14:29:00,660 DEBG received SIGCLD indicating a child quit
2019-07-17 14:29:02,665 INFO spawned: 'nzbget' with pid 114
2019-07-17 14:29:02,672 DEBG 'nzbget' stdout output:
[info] NZBGet configuration file exists
[info] Patching NZBGet config file for WebDir and ConfigTemplate locations...

2019-07-17 14:29:02,684 DEBG 'nzbget' stderr output:
/home/nobody/start.sh: line 26: 117 Segmentation fault /usr/local/bin/nzbget/nzbget -c /config/nzbget.conf -s 1>&-

2019-07-17 14:29:02,684 DEBG fd 8 closed, stopped monitoring (stdout)>
2019-07-17 14:29:02,684 DEBG fd 10 closed, stopped monitoring (stderr)>
2019-07-17 14:29:02,685 INFO exited: nzbget (exit status 139; not expected)
2019-07-17 14:29:02,685 DEBG received SIGCLD indicating a child quit
2019-07-17 14:29:05,690 INFO spawned: 'nzbget' with pid 126
2019-07-17 14:29:05,696 DEBG 'nzbget' stdout output:
[info] NZBGet configuration file exists
[info] Patching NZBGet config file for WebDir and ConfigTemplate locations...

2019-07-17 14:29:05,709 DEBG 'nzbget' stderr output:
/home/nobody/start.sh: line 26: 129 Segmentation fault /usr/local/bin/nzbget/nzbget -c /config/nzbget.conf -s 1>&-

2019-07-17 14:29:05,710 DEBG fd 8 closed, stopped monitoring (stdout)>
2019-07-17 14:29:05,710 DEBG fd 10 closed, stopped monitoring (stderr)>
2019-07-17 14:29:05,710 INFO exited: nzbget (exit status 139; not expected)
2019-07-17 14:29:05,710 DEBG received SIGCLD indicating a child quit
2019-07-17 14:29:05,710 INFO gave up: nzbget entered FATAL state, too many start retries too quickly

There have been no changes to the version of nzbget so I would suspect the issue will be related to corruption of your configuration file. Try creating a new path on the host for /config and then start the container, if it starts then you know this is the issue.

Sent from my CLT-L09 using Tapatalk

On 7/12/2019 at 9:48 AM, Magic815 said:

Just adding my voice to the mix. I also have noticed the "stuck at unpacking" issue with this docker container. I've just always manually restarted, which would fix the issue. For now, I've gone ahead and set up an hourly cron job to restart the docker, but I'll keep an eye on this thread to see if any more developments occur!

Any news on the unpacking issue. I just switched from SAB to this because it can actually download and saturate my line. I'd hate to go back to sab.....

Edited July 28, 20196 yr by Twitchstick

i'm using the "linuxserver/nzbget" version and i don't have that issue anymore using Currently installed: 21.0 version.
i used to have the stuck issue a few times even when i was testing it on my windows machine.
 

16 hours ago, Twitchstick said:

Any news on the unpacking issue. I just switched from SAB to this because it can actually download and saturate my line. I'd hate to go back to sab.....

To your earlier question (which you may have edited out), I use the plugin "CA User Scripts," which you can install from the Community Applications section. Once you have it installed, you just make another script called "NZBGet Restart" and have it say:
#!/bin/bash
docker restart binhex-nzbget

And then you can set it to whatever frequency you want.

+1 for the 'intermittently stops while unpacking' issue.  For me, this is a longstanding problem- many months.  I've gotten into the habit of deleting the download and later telling nzbget to 'download ramaining files' to return it to the queue.  Still, it stinks knowing that I MUST check the docker at least once a day, or things will pile up.  I REALLY  hope something shakes-out on this situation soon, because I know I suck at configuring/understanding dockers.  And I KNOW... that if I have to switch to another docker, I'm gonna have a devil of a time making it play nicely with binhex's sonarr.  

 

In case any info helps:  I'm still running 6.3.5, but I DO keep my dockers up-to-date. 

47 minutes ago, johnny121b said:

+1 for the 'intermittently stops while unpacking' issue.  For me, this is a longstanding problem- many months.  I've gotten into the habit of deleting the download and later telling nzbget to 'download ramaining files' to return it to the queue.  Still, it stinks knowing that I MUST check the docker at least once a day, or things will pile up.  I REALLY  hope something shakes-out on this situation soon, because I know I suck at configuring/understanding dockers.  And I KNOW... that if I have to switch to another docker, I'm gonna have a devil of a time making it play nicely with binhex's sonarr.  

 

In case any info helps:  I'm still running 6.3.5, but I DO keep my dockers up-to-date. 

Simple solution. User Scripts plugin, schedule this script to taste, once an hour or whatever.

#!/bin/bash
docker restart binhex-nzbget

Symptoms solved, no interaction required. The root CAUSE is still there, but I haven't seen any bad effects running this.

59 minutes ago, jonathanm said:

The root CAUSE is still there, but I haven't seen any bad effects running this.

Agreed.  I switched back to the "latest" Repository and run the restart script hourly - it's working fine.

 

I started to see a lot of failures unpacking and missing PAR files with binhex/arch-nzbget:19.1-1-02.  Since I'm back to the latest I haven't noticed as many.

On 6/1/2019 at 1:41 PM, jonathanm said:

Well, I pulled :test yesterday after you said it was built, but it's still using 5.7. Did I pull too early?

i got a new 'test' tagged image created with another possible fix for the unrar extract issue, fancy being my guinea pig again @jonathanm and seeing if it fixes the issue?

Edited September 3, 20196 yr by binhex

25 minutes ago, binhex said:

i got a new 'test' tagged image created with another possible fix for the unrar extract issue, fancy being my guinea pig again @jonathanm and seeing if it fixes the issue?

New :test downloaded. Keep in mind I don't generally interact with this, everything is automated. So it could be days before we get a result, weeks before it can be called fixed. I'll keep an eye on it regularly, but there is nothing in the queue at the moment.

39 minutes ago, jonathanm said:

New :test downloaded. Keep in mind I don't generally interact with this, everything is automated. So it could be days before we get a result, weeks before it can be called fixed. I'll keep an eye on it regularly, but there is nothing in the queue at the moment.

Thanks jonathanm, just to confirm your workaround of restarting the container is now disabled, right? :-)

2 minutes ago, binhex said:

Thanks jonathanm, just to confirm your workaround of restarting the container is now disabled, right? 🙂

Yes, I disabled that before I updated the container. I have no clue what happens when a docker restart is issued right in the middle of an update. 😀

On 9/3/2019 at 3:30 PM, jonathanm said:

Yes, I disabled that before I updated the container. I have no clue what happens when a docker restart is issued right in the middle of an update. 😀

i know its early days and promise i wont bug you a lot, just wondered how its going so far, any stuck unpacks?

1 hour ago, binhex said:

i know its early days and promise i wont bug you a lot, just wondered how its going so far, any stuck unpacks?

Not yet. However... is there anything you changed that would have messed with communication with the nntp server? I'm currently not able to use one of my servers (easynews) as it keeps saying blocking for 10 seconds, occasionally there will be an authentication failure message. I've logged in to my account online and nothing has changed, and I haven't seen any other people complaining.

Just now, jonathanm said:

is there anything you changed that would have messed with communication with the nntp server?

the only changes between the test tagged and latest is perhaps the base image has been updated, i would need to see when the last build of the base was and when the latest tagged image got built to be sure, there are no other changes to nzbget or networking changes.

On 9/6/2019 at 6:46 AM, binhex said:

the only changes between the test tagged and latest is perhaps the base image has been updated

Confirmed, unpacking still occasionally hangs. Just had a series of 10 files come in where 2 different files caused unpacking stalls.

Confirmed, unpacking still occasionally hangs. Just had a series of 10 files come in where 2 different files caused unpacking stalls.

Damnit [emoji19] ok and can you see in the logs that it was unrar and not a par check/repair going on?

Sent from my CLT-L09 using Tapatalk

1 hour ago, binhex said:

can you see in the logs that it was unrar and not a par check/repair going on?

Not definitively. I gave up trying to wade through a 2+GB log file.

On 9/9/2019 at 3:44 PM, binhex said:

Damnit ok and can you see in the logs that it was unrar and not a par check/repair going on?

Last log entry in a hung condition

 

Tue Sep 10 15:50:35 2019    INFO    Unpacking Blahhh
Tue Sep 10 15:50:35 2019    DETAIL    Unpacking into /downloads/complete/TV/Blahhh/_unpack

 

Restarted container, logging resumes, postprocessing resumes successfully, filenames have been redacted/replaced.

 

Tue Sep 10 16:06:30 2019    INFO    nzbget 21.0 server-mode
[?1049h[22;0;0t[1;24r(B[m[4l[?7h[?1h=[?25l[39;49m[39;49m[37m[40m[H[2J[39;49m[37m[40m[H[2J[37m[44m Files for downloading - 7 / 0 files in queue - 22.71 MB / 0 MB      Up 00:00:00[2;1H[37m[40m[1200] Blahhh/obfuscated.vol00[3;1H[1201] Blahhh/obfuscated.vol00[4;1H[1202] Blahhh/obfuscated.vol00[5;1H[1203] Blahhh/obfuscated.vol01[6;1H[1204] Blahhh/obfuscated.vol03[7;1H[1205] Blahhh/obfuscated.vol06[8;1H[1206] Blahhh/obfuscated.vol12[9;1H[37m[44m Messages[K
[32m[40mINFO    [37m[40mnzbget 21.0 server-mode
[23d[34m[47m 9 threads, 0 KB/s, 0 MB remaining, 1 post-job, Avg. 0 KB/s[K
[37m[44m(Q)uit | (E)dit | (P)ause | (R)ate | (W)indow | (G)roup | (T)ime | n(Z)b[K[80G(B[m[39;49m[37m[40mTue Sep 10 16:06:30 2019    INFO    Unpacking Blahhh
Tue Sep 10 16:06:30 2019    DETAIL    Unpacking into /downloads/complete/TV/Blahhh/_unpack
Tue Sep 10 16:06:30 2019    INFO    Unrar: UNRAR 5.60 beta 3 freeware      Copyright (c) 1993-2018 Alexander Roshal
Tue Sep 10 16:06:30 2019    INFO    Unrar: Extracting from obfuscated.part01.rar
Tue Sep 10 16:06:30 2019    INFO    Unrar: Extracting obfuscated.mkv

 

etc, etc.

 

The hang occurs right before this next line in a successful pass   INFO    Unrar: UNRAR 5.60 beta 3 freeware      Copyright (c) 1993-2018 Alexander Roshal

So, I'm assuming the unrar process never gets far enough to send the version back to nzbget.

 

Could be a red herring though, nzbget may just never get to the stage of actually invoking it. I haven't tried to examine the ps list in a hang state.

On 9/3/2019 at 9:18 AM, binhex said:

i got a new 'test' tagged image created with another possible fix for the unrar extract issue, fancy being my guinea pig again @jonathanm and seeing if it fixes the issue?

Did you build another test tag since you built the one you referenced on the 3rd? I just got an update indication, and it pulled data, so it looked like a real update. However, is it possible the test tag I pulled on the 3rd wasn't actually finished building yet so I got an old :test?

 

I'll continue to monitor for hangs either way.

Did you build another test tag since you built the one you referenced on the 3rd? I just got an update indication, and it pulled data, so it looked like a real update. However, is it possible the test tag I pulled on the 3rd wasn't actually finished building yet so I got an old :test?
 
I'll continue to monitor for hangs either way.

Sorry yes I did build another image I was playing around with the idea of including parcmdline but from what I read later on nzbget uses internal libpar2 so I don't think it will make any difference.

Thanks for the detailed post by the way, still thinking where I go next with this.

Sent from my CLT-L09 using Tapatalk

4 hours ago, binhex said:

still thinking where I go next with this.

If it helps at all, I was able to get in to the container while there was a non functional unpack, and did htop. There was only one unrar process, sitting there taking up cpu time. I killed it, and it respawned, but did NOT progress. I killed it multiple times, just to be sure, each time the CPU counter started over, but it never actually did anything. Dunno if I'm reading that correctly, but it seems to me that unrar isn't the problem, it's the invocation somehow. If unrar was at fault, I would expect killing it to allow a clean restart of the unrar process that would continue. Since it doesn't, it feels like its related to how nzbget is calling the unrar command.

 

Only restarting the container worked.

7 hours ago, jonathanm said:

If it helps at all

at this point, anything helps 🙂 so ive ruled out the version of unrar being the issue, as the test tagged version is now running the same version of unrar that was previously working in a earlier build and its still failing, so thats ruled out. so the two variables left are, the base os and nzbget itself, i may attempt to roll back to a earlier version of arch, however this will be tricky as its a rolling release so may be hard/impossible to do.

Is everyone having the unpacking stall issue or is this just a few people?  I'm trying to decide if I want to install the plugin or not...

 

Also, is there a way to use the VPN from your deluge plugin o cover your NZBGet plugin?

 

Thanks as always and kind regards,

craigr