Magic815 Posted July 12, 2019 Share Posted July 12, 2019 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! Quote Link to comment
ReVRiN Posted July 17, 2019 Share Posted July 17, 2019 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 Quote Link to comment
binhex Posted July 18, 2019 Author Share Posted July 18, 2019 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 quicklyThere 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 Quote Link to comment
Twitchstick Posted July 28, 2019 Share Posted July 28, 2019 (edited) 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, 2019 by Twitchstick Quote Link to comment
TRaSH Posted July 28, 2019 Share Posted July 28, 2019 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. Quote Link to comment
Magic815 Posted July 28, 2019 Share Posted July 28, 2019 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 Quote Link to comment
johnny121b Posted August 16, 2019 Share Posted August 16, 2019 +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. Quote Link to comment
JonathanM Posted August 16, 2019 Share Posted August 16, 2019 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. Quote Link to comment
ajgriglak Posted August 16, 2019 Share Posted August 16, 2019 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. Quote Link to comment
binhex Posted September 3, 2019 Author Share Posted September 3, 2019 (edited) 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, 2019 by binhex Quote Link to comment
JonathanM Posted September 3, 2019 Share Posted September 3, 2019 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. Quote Link to comment
binhex Posted September 3, 2019 Author Share Posted September 3, 2019 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? :-) Quote Link to comment
JonathanM Posted September 3, 2019 Share Posted September 3, 2019 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. 😀 Quote Link to comment
binhex Posted September 6, 2019 Author Share Posted September 6, 2019 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? Quote Link to comment
JonathanM Posted September 6, 2019 Share Posted September 6, 2019 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. Quote Link to comment
binhex Posted September 6, 2019 Author Share Posted September 6, 2019 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. Quote Link to comment
JonathanM Posted September 9, 2019 Share Posted September 9, 2019 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. Quote Link to comment
binhex Posted September 9, 2019 Author Share Posted September 9, 2019 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 Quote Link to comment
JonathanM Posted September 9, 2019 Share Posted September 9, 2019 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. Quote Link to comment
JonathanM Posted September 10, 2019 Share Posted September 10, 2019 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. Quote Link to comment
JonathanM Posted September 11, 2019 Share Posted September 11, 2019 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. Quote Link to comment
binhex Posted September 11, 2019 Author Share Posted September 11, 2019 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 Quote Link to comment
JonathanM Posted September 11, 2019 Share Posted September 11, 2019 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. Quote Link to comment
binhex Posted September 11, 2019 Author Share Posted September 11, 2019 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. Quote Link to comment
craigr Posted September 24, 2019 Share Posted September 24, 2019 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.