46 minutes ago, Jorgen said:

Looking back at other posts about Jackett and proxy, I think the easiest would be to not use it via proxy and instead bind it's network to the DelugeVPN container. See Q24 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
It will have its own quirks to work through though, read the other FAQ entries around network binding.


Sent from my iPhone using Tapatalk

So I tried that earlier, but I tried again just to confirm.

There's the start of Q24 from the FAQ...

 

Here's what I changed my Jackett container to:

1. Added the extra parameter as dictated. I assume "binhex-delugevpn" is the VPN container name? If not, I don't know what is.
2. Switched Network type to none
3. Removed what used to be the first environment variable. It was the port setting, which was previously 9117. 

Unfortunately, this results in a failed Docker restart. "The command failed." And then my docker page shows an orphan image where binhex-jackett used to be. So something isn't right. 

 

Thanks for the help so far. I'm eager to go down the path of binding Jackett to the VPN container. However, it seems awfully strange that Jackett literally has a setting for this (which would allow me to tell Jackett to just use privoxy), and we're unable to do that anymore...

As another point that privoxy should "just work", it looks like binhex stated we shouldn't need to do all this setup if we just want to use privoxy as usual.

 

Here's the post. Maybe I'm misunderstanding.

 

Now, what should we do? That I don't know. 

13 minutes ago, RollinDolan said:

So I tried that earlier, but I tried again just to confirm.

There's the start of Q24 from the FAQ...

 

Here's what I changed my Jackett container to:

1. Added the extra parameter as dictated. I assume "binhex-delugevpn" is the VPN container name? If not, I don't know what is.
2. Switched Network type to none
3. Removed what used to be the first environment variable. It was the port setting, which was previously 9117. 

Unfortunately, this results in a failed Docker restart. "The command failed." And then my docker page shows an orphan image where binhex-jackett used to be. So something isn't right. 

 

Thanks for the help so far. I'm eager to go down the path of binding Jackett to the VPN container. However, it seems awfully strange that Jackett literally has a setting for this (which would allow me to tell Jackett to just use privoxy), and we're unable to do that anymore...

That looks exactly like my setup which works. The only thing I can think of is there might be invisible characters or spaces in the Extra Parameters. Remove the orphaned image, reinstall Jackett from previous apps in CA and edit the Extra Parameters field by typing in the "--net..." line manually instead of copy/paste.

After it's downloaded and unpacked, copy the full run command and paste it here if the container still fails to start.

 

Which version of unraid are you on?

33 minutes ago, RollinDolan said:

As another point that privoxy should "just work", it looks like binhex stated we shouldn't need to do all this setup if we just want to use privoxy as usual.

 

Here's the post. Maybe I'm misunderstanding.

 

Now, what should we do? That I don't know. 

Well, it does work for Sonarr and Radarr, I think Binhex assumed Jackett would work the same, but it's obviously a special case from all the  posts here.

I don't know what to do about it either, apart from moving Jackett into the VPN network, maybe Binhex can weigh in at some point to clarify if there are other options.

 

Edit: wgstarks has the solution, see posts below

Edited March 4, 20215 yr by Jorgen

1 minute ago, Jorgen said:

Well, it does work for Sonarr and Radarr, I think Binhex assumed Jackett would work the same, but it's obviously a special case from all the  posts here.

I don't know what to do about it either, apart from moving Jackett into the VPN network, maybe Binhex can weigh in at some point to clarify if there are other options.

It works for me using the IP of the docker network. docker0 in my case.

46 minutes ago, betaman said:

Ok, so I pulled the latest docker image for DelugeVPN and manually added “VPN_OUTPUT_PORTS” env variable. I set value to port of NZBgetVPN (6789) but still can’t connect to it inside of the *arr containers?

 

Sorry mate, I re-read you initial post and I think I misunderstood your setup.

I thought you were binding the *arr apps to the delugeVPN network, but you are actually just using the proxy, right?

In that case I pointed you in the wrong direction and can't really help as I don't know how NzbGetVPN works.

29 minutes ago, RollinDolan said:

So I tried that earlier, but I tried again just to confirm.

There's the start of Q24 from the FAQ...

 

Here's what I changed my Jackett container to:

1. Added the extra parameter as dictated. I assume "binhex-delugevpn" is the VPN container name? If not, I don't know what is.
2. Switched Network type to none
3. Removed what used to be the first environment variable. It was the port setting, which was previously 9117. 

Unfortunately, this results in a failed Docker restart. "The command failed." And then my docker page shows an orphan image where binhex-jackett used to be. So something isn't right. 

 

Thanks for the help so far. I'm eager to go down the path of binding Jackett to the VPN container. However, it seems awfully strange that Jackett literally has a setting for this (which would allow me to tell Jackett to just use privoxy), and we're unable to do that anymore...

The SpaceInvader video did not delete the port variable.  I'm not sure if that makes a difference.  I know it is contrary to what the instructions specify.

2 minutes ago, wgstarks said:

It works for me using the IP of the docker network. docker0 in my case.

Ah, interesting. Could you share a screenshot of the Jacket proxy settings?

Is that a 172.x.x.x IP?

1 minute ago, Jorgen said:

Ah, interesting. Could you share a screenshot of the Jacket proxy settings?

Is that a 172.x.x.x IP?

 

Sorry, I can’t remember the terminal command to lookup the IP.

2 minutes ago, wgstarks said:

 

Sorry, I can’t remember the terminal command to lookup the IP.

 

No terminal command required, it's shown on the docker page in unraid:

 

One thing to keep in mind if you go down this route (pun intended) is that the docker IP is dynamcially assigned and could change on restart of containers or the unraid server. If things always start in the same order it probably won't, but just be aware of it if things suddenly stops working again.

 

18 minutes ago, Jorgen said:

Well, it does work for Sonarr and Radarr, I think Binhex assumed Jackett would work the same, but it's obviously a special case from all the  posts here.

I don't know what to do about it either, apart from moving Jackett into the VPN network, maybe Binhex can weigh in at some point to clarify if there are other options.

Sorry, I should have been more specific. By "just work", I meant that binhex's post looked like I should not need to route anything through the VPN container. I did not previously route anything through the VPN container - instead, I just told Jackett to use privoxy as its proxy.

 

The "working solution" for Sonarr and Radarr is routing them through the VPN container. I already have a working method to that (using Jackett in Sonarr and Radarr).

 

Note - Jackett through privoxy in lieu of everything-through-container seems to be binhex's preferred method. Yet we can't get guidance on it.

 

To answer your above question - I'm on Unraid 6.9.0

 

I also tried wgstarks' method: I used ifconfig to get the local IP of my docker container (I wasn't sure if you meant the deluge docker or the jackett docker, so I tried both...) and it didn't work. Same errors after saving the new IP through the Jackett gui. It was a very similar looking 172.xxx address.

Edited March 4, 20215 yr by RollinDolan

3 minutes ago, RollinDolan said:

Sorry, I should have been more specific. By "just work", I meant that binhex's post looked like I should not need to route anything through the VPN container. I did not previously route anything through the VPN container - instead, I just told Jackett to use privoxy as its proxy.

 

The "working solution" for Sonarr and Radarr is routing them through the VPN container. I already have a working method to that (using Jackett in Sonarr and Radarr).

 

Note - Jackett through privoxy in lieu of everything-through-container seems to be binhex's preferred method. Yet we can't get guidance on it.

 

To answer your above question - I'm on Unraid 6.9.0

 

I also tried wgstarks' method: I used ifconfig to get the local IP of my docker container (I wasn't sure if you meant the deluge docker or the jackett docker, so I tried both...) and it didn't work. Same errors after saving the new IP through the Jackett gui. It was a very similar looking 172.xxx address.

In Jackett proxy config you should use the 172.17.x.x IP of the DelugeVPN container. I think this also assumes that both Jackett and DelugeVPN containers are using the same docker network, which is bridge by default:

 

19 minutes ago, Jorgen said:

Sorry mate, I re-read you initial post and I think I misunderstood your setup.

I thought you were binding the *arr apps to the delugeVPN network, but you are actually just using the proxy, right?

In that case I pointed you in the wrong direction and can't really help as I don't know how NzbGetVPN works.

No worries. Yeah I’m just using Privoxy thru DelugeVPN. In theory, NZBgetVPN should behave just like DelugeVPN except that binnex doesn’t manage a version of it...

26 minutes ago, Jorgen said:

In Jackett proxy config you should use the 172.17.x.x IP of the DelugeVPN container. I think this also assumes that both Jackett and DelugeVPN containers are using the same docker network, which is bridge by default:

 

Right, thanks. I tried that - no dice.

 

However, I'm now noticing that my deluge docker logs are showing "Sending 'down' command to WireGuard due to dns failure"

I didn't change my wireguard configs. I didn't change any of my PrivateInternetAccess config. I didn't change anything related to DNS / name servers.

 

This worked yesterday. Sigh... guess I'll figure out what else got broken from the update.

9 minutes ago, RollinDolan said:

Right, thanks. I tried that - no dice.

 

However, I'm now noticing that my deluge docker logs are showing "Sending 'down' command to WireGuard due to dns failure"

I didn't change my wireguard configs. I didn't change any of my PrivateInternetAccess config. I didn't change anything related to DNS / name servers.

 

This worked yesterday. Sigh... guess I'll figure out what else got broken from the update.

ok, there was a bug in the container updates yesterday in regards to wireguard. Try forcing an update now and see if it fixes it, binhex pushed a fix a few hours ago.

4 hours ago, Jorgen said:

ok, there was a bug in the container updates yesterday in regards to wireguard. Try forcing an update now and see if it fixes it, binhex pushed a fix a few hours ago.

Updated the container and it is now working, thanks Jorgen.

Would someone be able to help me install 3rd party plugins? Or are they just still broken as I have read previously?

 

I have the latest unRAID and container. Installing from the plugin menu is broken, never had that working. So I tried dropping the egg in to the plugin folder (specifically LabelPlus and AutoRemovePlus), both py2.6 and py2.7 versions. They weren't recognized by the plugin menu, even after a restart. Clicking install creates a [File ObjectList] file in the plugin folder which does nothing. 

 

So I did some reading, and figured the python versions were out of sync, and I read that someone recompiled it from the plugin source, so I did that and now I have new egg files with py3.9. Getting closer, these can now be recognized in the plugin menu. When I try to check them, they tick, and then I click apply and/or OK, but nothing happens, and I go immediately back into the menu and they are unticked. Won't stay put. I tried adding them to the conf manually, but this does nothing.

 

Any other ideas? Thanks in advance.

1 hour ago, xMaverickx said:

Any other ideas? Thanks in advance.

Have you tried adding the new egg directly to the plugins folder? You also may need to remove -pyX.X from the file name.

Is there anything to be worried about with Privoxy constantly restarting? I "think" it's working, but logs clearly show its restarting every 30s even after this latest update.

Could someone post how to roll back to the previous version?  Based on what I read, it may take awhile to get the new version working.

18 minutes ago, Mark McDonald said:

Could someone post how to roll back to the previous version?  Based on what I read, it may take awhile to get the new version working.

type a colon and your desired release version after the name in the repository field. You can get the release numbers from the GitHub link in the first post.

Hello, both Sonarr and Radarr recently have been unable to connect to Deluge. Both return the following error under System:

 

Quote

Unable to communicate with Deluge on MyServer. The operation has timed out.: 'http://192.168.1.146:8112/json'

 

I suspect this may be related to Privoxy, as my Deluge log shows the following repeating over and over:

 

2021-03-04 19:35:47,139 DEBG 'watchdog-script' stdout output:
[info] Privoxy not running

2021-03-04 19:35:47,143 DEBG 'watchdog-script' stdout output:
[info] Attempting to start Privoxy...

2021-03-04 19:35:48,153 DEBG 'watchdog-script' stdout output:
[info] Privoxy process started
[info] Waiting for Privoxy process to start listening on port 8118...

2021-03-04 19:35:48,159 DEBG 'watchdog-script' stdout output:
[info] Privoxy process listening on port 8118

 

Up until recently everything was working fine. My VPN is PIA. Anyone know where to start?

---

✔️SOLVED: I had to add my server's IP in both Sonarr and Radarr under Settings > General > Proxy > "Addresses for the proxy to ignore"

 

This is described in Q26 in the documentation here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Edited March 5, 20215 yr by Odessa
Solved

17 hours ago, wgstarks said:

Have you tried adding the new egg directly to the plugins folder? You also may need to remove -pyX.X from the file name.

 

Tried both of those things and no change.

6 hours ago, Odessa said:

Hello, both Sonarr and Radarr recently have been unable to connect to Deluge. Both return the following error under System:

 

 

I suspect this may be related to Privoxy, as my Deluge log shows the following repeating over and over:

 

2021-03-04 19:35:47,139 DEBG 'watchdog-script' stdout output:
[info] Privoxy not running

2021-03-04 19:35:47,143 DEBG 'watchdog-script' stdout output:
[info] Attempting to start Privoxy...

2021-03-04 19:35:48,153 DEBG 'watchdog-script' stdout output:
[info] Privoxy process started
[info] Waiting for Privoxy process to start listening on port 8118...

2021-03-04 19:35:48,159 DEBG 'watchdog-script' stdout output:
[info] Privoxy process listening on port 8118

 

Up until recently everything was working fine. My VPN is PIA. Anyone know where to start?

see recommended post at the top of this page.

Hi, 

 

I am having issues with Deluge and the support button on the container send me here. 

Deluge is downloading fine but completed downloads are not removed. As a result my hdd fills up and it stops downloading. I have seeding set to 0 so when they are done downloading they should stop all activity. 

 

I am using Binhex Sonarr. Sonarr is moving the dowloads but not removing them from Deluge. 

I tried installing the autoremoveplus plugin but Deluge does not accept the .egg file. It just creates an [objectfilelist].

 

Could anyone help me figuring out why completed downloads are not deleted?