Jump to content
binhex

[Support] binhex - NZBGet

164 posts in this topic Last Reply

Recommended Posts

25 minutes ago, debit lagos said:

 

Sent you a message.

 

Thanks. I might look into that. 

 

Is is there a way to rollback version back to version before this one?  Pretty new to unraid and using dockers. 

Share this post


Link to post
2 hours ago, rmilyard said:

 

Thanks. I might look into that. 

 

Is is there a way to rollback version back to version before this one?  Pretty new to unraid and using dockers. 

 

I've been looking and can't find anything specific.  I know there is probably a "manual way" to do it, but not sure what that process looks like.

 

For the masses... I can confirm that the "develop branch" has a fix (what ever the fix actually is) that makes my setup work without getting stuck at UNPACKING.  Mileage may vary.

  • Like 1

Share this post


Link to post

I'm having a issue starting up the docker container.  Image below.

 

https://imgur.com/a/shOyQX8

 

It's telling me something is running on 6789 - but as far as I know nothing's there.  

 

When I log into the docker and check, it says that java is running on 6789?

Share this post


Link to post

Guys,

 

 I gotta say as a noob to unRaid, I'm impress with both the software and the community. I have nzbget and sonarr set up and they seem to be working fine. Here is my issue. I can ONLY get sonarr to connect to nzbget on its internal (172.17.0.x) address and NOT the servers IP:Port address. Normally I wouldn't care, but the internal ports change on restart and I have to fix sonarr before it all works again. What have I done wrong and how can I fix it?

Share this post


Link to post
On 6/19/2018 at 5:22 PM, grizzle33 said:

I'm having a issue starting up the docker container.  Image below.

 

https://imgur.com/a/shOyQX8

 

It's telling me something is running on 6789 - but as far as I know nothing's there.  

 

When I log into the docker and check, it says that java is running on 6789?

 

that screenshot is a classic symptom of clashing ports, you have two options, find out what the other container is thats running on host port 6789 and stop it, or change the host port number for this container to something else, say 6790 for instance, this will then stop the clash from happening.

Share this post


Link to post
1 hour ago, Big Dave Diode said:

Guys,

 

 I gotta say as a noob to unRaid, I'm impress with both the software and the community. I have nzbget and sonarr set up and they seem to be working fine. Here is my issue. I can ONLY get sonarr to connect to nzbget on its internal (172.17.0.x) address and NOT the servers IP:Port address. Normally I wouldn't care, but the internal ports change on restart and I have to fix sonarr before it all works again. What have I done wrong and how can I fix it?

 

ok could you post a screenshot of unraid web ui/docker tab/select advanced view top right and then screenshot the entire screen and post it here, that will tell me what ports you are running things on for a start. just to confirm you are correct, you def should not be referencing the internal docker network (as in 172.x.x.x) but instead should be using the unraid host ip and the port you specified when you first configured the container.

Share this post


Link to post
1 hour ago, Big Dave Diode said:

As requested. Thanks for your help.

It's very atypical to have an unraid box with a publicly routable IP. What is your network topology?

Share this post


Link to post

I used to own those IP's. I sold them, but never go around to readdressing my network. Last time I checked, they were in use by a mining company in Canada. Since I was highly unlikely to link to them, I didn't bother to change anything. Laziness is my middle name. I should address (ahem) the problem, but since it ain't broke, it keeps being pushed back.

Share this post


Link to post
12 hours ago, Big Dave Diode said:

I used to own those IP's. I sold them, but never go around to readdressing my network. Last time I checked, they were in use by a mining company in Canada. Since I was highly unlikely to link to them, I didn't bother to change anything. Laziness is my middle name. I should address (ahem) the problem, but since it ain't broke, it keeps being pushed back.

 

This could be your issue, possibly nzbget/sonarr are coded in such a way as to expect private network ranges, so maybe thats causing the problem, i certainly would recommend sorting that out once and for all and get yourself on 192.168.x.x or 10.x.x.x range for your home lan its going to make your life easier in the long run.

Share this post


Link to post

I mean, maybe?

 

The only thing that makes this interesting is I can access the web interface of nzbget with no issues at all. The Host IP works fine. I can access Sonarr by its Host IP as well. Both tools work fine running as a daemon as well. I will keep digging. Thanks for replying I appreciate your work on this. It truly is amazing how smoothly it all works together.

Share this post


Link to post
I mean, maybe?
 
The only thing that makes this interesting is I can access the web interface of nzbget with no issues at all. The Host IP works fine. I can access Sonarr by its Host IP as well. Both tools work fine running as a daemon as well. I will keep digging. Thanks for replying I appreciate your work on this. It truly is amazing how smoothly it all works together.
It is a maybe granted, all I can say is this does work out of the box for a vast majority of users, you happen to be the first person with this particular issue who just happens to be running their lan on a public IP range, coincidence, maybe

Sent from my SM-G935F using Tapatalk

Share this post


Link to post
On 6/17/2018 at 10:13 PM, binhex said:

I've not rolled back to a previous version before, so forgive the basic question...

 

Is there still a notification when a new version comes out if you're no longer on latest, or do you have to keep an eye out?

Share this post


Link to post
10 hours ago, Cessquill said:

I've not rolled back to a previous version before, so forgive the basic question...

 

Is there still a notification when a new version comes out if you're no longer on latest, or do you have to keep an eye out?

 

there will be no notification, as you will be targeting a tagged version and thus it wont get updated. you can keep checking for a new release by looking here and watching out for a version change as this is what triggers a new build:-

 

https://www.archlinux.org/packages/community/x86_64/nzbget/

 

i will try and remember to post on here if i see a new release triggered, but as it could be anything from hours to weeks away i cant make any promises, my memory isnt what it used to be :-).

Share this post


Link to post
8 minutes ago, binhex said:

 

there will be no notification, as you will be targeting a tagged version and thus it wont get updated. you can keep checking for a new release by looking here and watching out for a version change as this is what triggers a new build:-

 

https://www.archlinux.org/packages/community/x86_64/nzbget/

 

i will try and remember to post on here if i see a new release triggered, but as it could be anything from hours to weeks away i cant make any promises, my memory isnt what it used to be :-).

Logically, I didn't think unRaid would raise a notification, since I'd gone off piste.  I kept your page full of builds open  and will refresh (or look at the above link).  Tried to hold out as long as I could.

 

Thanks for getting back to me :)

Share this post


Link to post

Having a problem with the unpack child process just looping the extraction. The "messages" tab shows: "Restarting hanging child process for unpack...."

 

The extracted destination file just keeps looping in size until it looks to be fully extracted, then starts over. I observed this by rapidly refreshing and watching the file size grow, then go back to near-zero, repeat.

 

I am running no pp-scripts and using sonarr, but I don't believe sonarr ever gets around to handling the file. I also have only "unrar" in the UnrarCmd setting.

 

In the nzbget container console I am able to get the same archive to extract using unrar e <file> <dest>. Observing that, I changed the UnrarCmd setting to "unrar e" which I thought had fixed the problem, but while typing this, it just got hung up on another archive.

 

Any ideas here? I'm not sure it's an NZBget problem or just a problem with this docker container since it's related to unrar.

 

Next, I may try the -o- switch and see what happens since it technically might stop it from starting over since the destination file exists already.

 

Thanks!

Share this post


Link to post
2 minutes ago, jonesy8485 said:

Any ideas here? I'm not sure it's an NZBget problem or just a problem with this docker container since it's related to unrar.

Scroll to the top of this page / tail end of previous.

 

Long story short, it's a known issue with NZBget.  Easiest solution is to install earlier version until an update is released (instructions above).

  • Like 1

Share this post


Link to post
2 minutes ago, Cessquill said:

Scroll to the top of this page / tail end of previous.

 

Long story short, it's a known issue with NZBget.  Easiest solution is to install earlier version until an update is released (instructions above).

 

Ah geez, I've been googling this all day but this never came up because I wasn't using any of the same keywords.

 

I'll do this.

 

Thanks and I apologize for not noticing the comments up there!

Share this post


Link to post
On 6/17/2018 at 3:50 PM, debit lagos said:

 

I've been looking and can't find anything specific.  I know there is probably a "manual way" to do it, but not sure what that process looks like.

 

For the masses... I can confirm that the "develop branch" has a fix (what ever the fix actually is) that makes my setup work without getting stuck at UNPACKING.  Mileage may vary.

 

What do you know about this problem? I'm just curious what it really is and why it just now popped up. Any references you can share?

Share this post


Link to post

Looks like I too had to role back to v19 due to the amount of errors I was getting with the binhex-radarr and binhex-sonarr containers.   Those apps would continuously loose connectivity to binhex-nzbget(v20), but rolling back to v19, everything worked instantly.  

Share this post


Link to post
On 6/30/2018 at 7:42 PM, jonesy8485 said:

 

What do you know about this problem? I'm just curious what it really is and why it just now popped up. Any references you can share?

 

the issue looks to be a bug in the version of unrar that was installed in the base image i created, ive now bumped the version of unrar up to 5.6 stable, if you are having unpack issues then please check for updates and pull down latest.

  • Like 1

Share this post


Link to post
 
the issue looks to be a bug in the version of unrar that was installed in the base image i created, ive now bumped the version of unrar up to 5.6 stable, if you are having unpack issues then please check for updates and pull down latest.
Thanks for the update! I will change back to latest repository and update when I get a chance.

I'll prolly buy you a beer, as well.

Sent from my Pixel XL using Tapatalk

Share this post


Link to post
21 hours ago, jonesy8485 said:

Thanks for the update! I will change back to latest repository and update when I get a chance.

I'll prolly buy you a beer, as well. emoji6.png

Sent from my Pixel XL using Tapatalk
 

 

and the verdict is?....:-)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now