[Support] binhex - NZBGet


352 posts in this topic Last Reply

Recommended Posts

Just now, jonathanm said:

Zero intervention required. I've had the following as a user scripts entry running hourly for probably a year.


#!/bin/bash
docker restart binhex-nzbget

Never have to touch it.

 

That's certainly a useable workaround, but in the long run I'd feel better finding the actual cause of these hung unpack processes.

 

Link to post
  • Replies 351
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I and other users are seeing the same issue. I've discovered a few issues that seem to be related. First is that the par check/repair stage seems to fail randomly. Sometimes nzbget reports 'PAR Succes

So today I noticed all my downloads are stuck unpacking. They seem to unpack, delete and then start over and over. So files never get to steps. 

Yep just pushed a change through, should get you back up and running guys. Sent from my LG-V500 using Tapatalk

Posted Images

1 minute ago, AgentXXL said:

 

That's certainly a useable workaround, but in the long run I'd feel better finding the actual cause of these hung unpack processes.

 

Oh, a fix would be much better, but I don't like SAB, and this workaround hasn't caused me any issues, so I'm ok with it.

Link to post
1 minute ago, jonathanm said:

Oh, a fix would be much better, but I don't like SAB, and this workaround hasn't caused me any issues, so I'm ok with it.

I switched to back to SAB about 1 month ago as it was too annoying because of this.   Hate it, but I'd rather have something that actually works properly

Link to post
Just now, Squid said:

I switched to back to SAB about 1 month ago as it was too annoying because of this.   Hate it, but I'd rather have something that actually works properly

Interesting. Honestly until people bring it up, I forget I have the restart script in place. What was so annoying to you? Or is it just the principle of the matter?

Link to post

 

Just now, jonathanm said:

What was so annoying to you?

The simple fact that everything just plain stopped.  I found restarts (manually done) didn't always work, and more or less narrowed it down to specific nzb files that were screwing it up (but it was a very common issue).  Just threw up my hands, took the plunge backwards and haven't looked back again.

Link to post
20 minutes ago, xilo said:

Given that his response was a week ago, and he is monitoring the issue tracker on github, its worth the effort to put in a bug report.

 

I've created an issue if anyone wants to add their $0.02

 

https://github.com/nzbget/nzbget/issues/686

You may want to amend your report disclosing that it is concerning a docker container, not a full install. I don't believe the issue occurs on a normal install, but I could be wrong. Please read through this thread to get a sense of the history and what has already been tried to troubleshoot the issue.

Link to post
1 hour ago, jonathanm said:

You may want to amend your report disclosing that it is concerning a docker container, not a full install. I don't believe the issue occurs on a normal install, but I could be wrong. Please read through this thread to get a sense of the history and what has already been tried to troubleshoot the issue.

Done.  Thank you for the suggestion.  I have read through this thread already, but sometimes hard to follow for me.  NZBGet author suggested building the container mysef/compiling within the container.  I believe this is beyond my skill set, so I am going to try the nzbget container from linuxserver.io to see if I have any luck before I give up and go back to Sabnzbd.

Link to post
11 minutes ago, xilo said:

Done.  Thank you for the suggestion.  I have read through this thread already, but sometimes hard to follow for me.  NZBGet author suggested building the container mysef/compiling within the container.  I believe this is beyond my skill set, so I am going to try the nzbget container from linuxserver.io to see if I have any luck before I give up and go back to Sabnzbd.

I'll save you the time.  Don't bother.  Both are affected. But it is my belief that this is something related to specific nzbs as some work fine no problems, but my experience showed that the same nzb would fail consistently.   I tried going back a couple of versions on lsio to no avail before I tried binhex, and then just switched to sab.  

Link to post
16 minutes ago, Squid said:

I'll save you the time.  Don't bother.  Both are affected. But it is my belief that this is something related to specific nzbs as some work fine no problems, but my experience showed that the same nzb would fail consistently.   I tried going back a couple of versions on lsio to no avail before I tried binhex, and then just switched to sab.  

Kind of early to tell, but I did a 250 nzb download test and we didn't hang on a single one.  It looks promising, but I won't get my hopes up.

Link to post
  • 3 weeks later...

Is there an easy way to migrate to the linuxserver nzbget? I have a bunch of things queued and integrated into sonarr so would prefer to not lose that automation. if i could install the docker, copy over appdata, set up shares identically and not lose progress that'd be great, but am not sure.

Link to post
15 hours ago, MaxBottomTime said:

Is there an easy way to migrate to the linuxserver nzbget? I have a bunch of things queued and integrated into sonarr so would prefer to not lose that automation. if i could install the docker, copy over appdata, set up shares identically and not lose progress that'd be great, but am not sure.

I've done exactly this.

 

Just rename this folder:

/mnt/user/appdata/binhex-nzbget

 

to this:

/mnt/user/appdata/nzbget

Edited by ConnectivIT
Link to post
15 hours ago, MaxBottomTime said:

Thanks! Your Queue then transferred properly and sonarr continued to peck away at things and import those files?

It was a while ago since I did this, but I believe so.

 

edit: (if you're using the internal docker name "binhex-nzbget" inside sonarr to reference the network name of nzbget, then obviously you'll need to change this to just "nzbget")

Edited by ConnectivIT
Link to post
  • 3 weeks later...

just checked the sizes of my various containers and noticed an anomaly.  My binhex-nzbget container is currently taking up 7GB of space which is approx 7-10x bigger than any other container. I don't know if its growing, will keep an eye on this.

 

Is this typical? if not what could be the cause?

 

FYI, my /data <--> /mnt/user/downloads/ and my /config <--> /mnt/user/appdata/binhex-nzbget

Link to post
2 hours ago, EvilTiger said:

what could be the cause?

 

FYI, my /data <--> /mnt/user/downloads/ and my /config <--> /mnt/user/appdata/binhex-nzbget

If nzbget is configured to save files anywhere other than /data/* and /config/* the files will end up in the docker image.

Link to post
18 hours ago, jonathanm said:

If nzbget is configured to save files anywhere other than /data/* and /config/* the files will end up in the docker image.

Hi @jonathanm, Thank you for the reply. In my case all 'Paths' are defined as ${AppDir} or ${MainDir}. For the former, this is an environmental variable which is a volume mapping per my original post (/data <--> /mnt/user/downloads/) and the latter, is a nzbget variable which points to ${AppDir} and defines a sub directory within.

 

I cannot find any other references to any other location within the configuration of nzbget.  Any other ideas??

 

What is a typical size of other users nzbget containers?

 

Thank you in advance.

Link to post
5 minutes ago, EvilTiger said:

What is a typical size of other users nzbget containers?

binhex-nzbget 657 MB 11.1 MB 7.26 MB

 

9 minutes ago, EvilTiger said:

Any other ideas??

Post a screenshot of your Settings, Paths in NZBGet

Link to post
10 minutes ago, jonathanm said:

Set MainDir to /data

thank you, that should do it as I now see it created the sub dirs. in the correct location. I assume I need to remove the directories that were created within the container.

 

actually, I cannot find where the 7gb is being consumer, I assume the process cleans up after itself and the 7gb is the highwater mark of where it was at one point in time. if, how do I shrink the container so its not using almost 50% of my docker.img allocation?

 

again, much appreciated.

 

Edited by EvilTiger
revised question
Link to post

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.