Jorgen
-
Posts
269 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Jorgen
-
-
Sorry, I am not well versed in Linux.
Where do these files go; (path(es)).
/xxxx
and on the flash, cache or both?
I can do this, just need the pointers.
Thanks again!
Sorry I won’t be able to help, my unRAID server is in storage for a month due to house renovations so I would just be guessing at things to try.
Did you already try just copying the wg config file from appdata on one of the Binhex VPN dockers?
Sent from my iPhone using Tapatalk -
I received an "escalated" reply from PIA and...
"I understand that you needed a Wireguard configuration file.
Please let know that PIA only has a configuration file available for OpenVPN. Wireguard can only be used using the PIA client app."
Hmm that doesn’t seem right. PIA themselves have published scripts to use with wireguard outside their app:
https://www.privateinternetaccess.com/helpdesk/kb/articles/manual-connection-and-port-forwarding-scripts
Sent from my iPhone using Tapatalk -
While PIA does provide a 'script', it fails at the end when attempting to get the certificate from them. I tried working with their support, but we've just been running in circles.
I don’t have a solution for you, but many of us are using wireguard and PIA in binhex’s excellent VPN enabled containers. Maybe you could look into the script he’s using to get the required settings? Or even set up a container and copy the wg config file?
Sent from my iPhone using Tapatalk -
Hmmmm, OK. In the "Wireguard" folder in AppData, the conf file shows "ca-toronto.privacy.network:1337" for the endpoint, which is the server I'd have picked anyway...
Is that static, or does it change when restarted? I don't recall ever setting that, but maybe I did.
It’s static. Can’t remember what the default one is, but you can change it to whichever supported endpoint you wish and it should persist from that point.
Sent from my iPhone using Tapatalk-
1
-
-
Looked thru but I am sure I must have missed it. I have everything working and connected (thanks again for your hard work binhex). When I click on the docker gif I would normally get a list of options (like edit, console, gui etc). When I click on them now (only the ones connected thru localhost) I no longer get the web interface option. I must type in the server address with port to get to radarr or sonarr. Not a big deal but wondering if I skipped a step and can somehow get this back. If thats how it has to be I am still very happy. Just curious if I missed a part of the fix. Thanks again
That’s how it works when binding the network.
Sent from my iPhone using Tapatalk -
I would much rather have a no longer supported v2 than a broken v3, please provide information on how I can go back to v2.
From a few posts up. But you’re probably better off in the long run to try to get sonarr v3 working with the seed box.
However, if you want to stick on Sonarr v2 then please do the following:-
- Go to unRAID Web UI/Docker/left click Sonarr/Edit and change the value for 'Repository' to:-
binhex/arch-sonarr:2.0.0.5344-1-04
- Click apply to pull down v2 image.
Sent from my iPhone using Tapatalk -
[mention]strykn [/mention] [mention]nowhere99 [/mention] did you see the pinned post at the top of this thread and followed the instructions?
Edit: Sorry! The post is pinned to the delugeVPN thread, see here:
https://forums.unraid.net/topic/44109-support-binhex-delugevpn/?do=findComment&comment=951973 -
Is it possible to just restore just one subdirectory of appdata? I am having issues with one docker and want to restore. My backup is a tar file that is 39.4 GB. Can I extract just the appdate\unifi folder? If so, how would I do this?
Yes, using tar from the command line.
Here’s an example:
https://www.linux.org/threads/list-tar-contents-only-first-level-then-subdirectory-extract.10491/
Sent from my iPhone using Tapatalk -
1 hour ago, Squnkraid said:
I added all the containers using Delugevpn to VPN_INPUT_PORTS and they all became accessible again! And they can communicate with each other too.
But SABnzbd is running outside the Delugevpn container (no need for VPN) and I can't get Sonarr,Radarr and NZBHydra to communicate with SABnzbd. I re-ran every step and the only thing I'm not sure about is the Proxy Settings
Sonarr > Settings > General > Proxy Settings
- Use Proxy = Yes
- Proxy Type = HTTP(S)
- Hostname = ip of server / localhost (tried both)
- Port = 8118
- Username = "empty"
- Password = "empty"
- Addres for the proxy to ignore = ip of server / 192.168.*.* (wildcard for LAN) (tried both)
Sounds like your routing Sonarr et al through the DelugeVPN container network?
In that case, you should NOT use the proxy settings in Sonarr. It's one or the other, not both.
You should also add the SABnzbd ports to VPN_OUTPUT_PORTS environment variable. Because Sonarr running INSIDE the DelugeVPN container network, needs to be allowed to talk OUT to the SAB ports running outside the DelugeVPN network.
This is explained in Q27 here https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
Of course, if you are not routing the apps through the DelugeVPN network this is not applicable.
-
9 hours ago, workermaster said:
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?
Sonarr is supposed to remove the torrent from Deluge after it reaches the defined ratio, but I never got that to work either.
AutoRemovePlus plugin is the way to go in my opinion.
The most likely reason the egg isn't accepted for you is that the Python version in this container was recently updated to 3.9.
If you have the 3.8 egg in the plugin folder already, simple rename it to 3.9 (see below) and restart the container:
AutoRemovePlus-2.0.0-py3.9.eggIf you don't have it, download the 3.8 version from here: https://forum.deluge-torrent.org/viewtopic.php?f=9&t=55733
Put the egg into the plugin folder, rename it to 3.9 and restart container.
-
3
-
-
7 hours ago, Djoss said:
Arguments passed to the post processing script have always been the same. See https://github.com/jlesage/docker-handbrake#hooks
So I'm not sur how your script worked, since the watch folder path is never passed to the script... and the first argument should be the conversion state.
Since you are using a single watch folder, you can only set the watch folder like this:
WATCH_FOLDER=/watchThanks, hardcoding "/watch" made it work again, of course.
Just for my understanding though, am I misinterpreting the table on the hooks page? I'm using post_watch_folder_processing.sh
-
Hi Djoss,
I've been running this container for a looooong time without any problems, using the automatic watch folder workflow and a post_watch_folder_processing script to stop the container after processing if the watch folder is empty.
Sometime during the last few months (maybe longer) the script has stopped working as intended, with this in the log:
[autovideoconverter] Conversion ended successfully. [autovideoconverter] Removed /watch/moviename.mkv'. [autovideoconverter] Watch folder '/watch' processing terminated. [autovideoconverter] Executing post watch folder processing hook... post-watch folder processing: Watch folder = /watch/BDMV watch folder not empty, won't shut down [autovideoconverter] Post watch folder processing hook exited with 0 [autovideoconverter] Change detected in watch folder '/watch'. [autovideoconverter] Processing watch folder '/watch'... [autovideoconverter] Watch folder '/watch' processing terminated.
Here's the script:#!/bin/sh # # This is an example of a post watch folder processing hook. This script is # always invoked with /bin/sh (shebang ignored). # # The argument of the script is the path to the watch folder. # WATCH_FOLDER=$1 echo "post-watch folder processing: Watch folder = $WATCH_FOLDER" if [ -d "/$WATCH_FOLDER" ] && [ -z "$(ls -A "$WATCH_FOLDER")" ] then echo "watch folder empty, shutting down" killall -sigterm ghb else echo "watch folder not empty, won't shut down" fiI don't understand where /watch/BDMV is coming from? Are you able to shed some light on this for me, please?
Has the argument value changed recently? Is Handbrake adding a temporary BDMV folder during processing? Or have I added another watch folder somehow without realising?
In the container settings, the watch folder is set to /mnt/user/Media/Handbrake_hotfolder/watch/
Thanks in advance
Jorgen
Edit: I only have one watch folder defined in the container settings, and no optical drives passed through.
Full run command:
root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker create --name='HandBrake' --net='bridge' -e TZ="Australia/Sydney" -e HOST_OS="Unraid" -e 'AUTOMATED_CONVERSION_PRESET'='My Presets/Mathias_MKV_720p30_v2' -e 'AUTOMATED_CONVERSION_FORMAT'='mkv' -e 'AUTOMATED_CONVERSION_KEEP_SOURCE'='0' -e 'AUTOMATED_CONVERSION_OUTPUT_SUBDIR'='' -e 'AUTOMATED_CONVERSION_OUTPUT_DIR'='/output' -e 'AUTOMATED_CONVERSION_NON_VIDEO_FILE_ACTION'='ignore' -e 'DISPLAY_WIDTH'='1280' -e 'DISPLAY_HEIGHT'='768' -e 'USER_ID'='99' -e 'GROUP_ID'='100' -e 'APP_NICENESS'='15' -e 'UMASK'='000' -e 'X11VNC_EXTRA_OPTS'='' -e 'AUTOMATED_CONVERSION_SOURCE_STABLE_TIME'='5' -e 'AUTOMATED_CONVERSION_SOURCE_MIN_DURATION'='10' -e 'SECURE_CONNECTION'='0' -e 'AUTOMATED_CONVERSION_CHECK_INTERVAL'='5' -e 'AUTOMATED_CONVERSION_MAX_WATCH_FOLDERS'='5' -e 'AUTOMATED_CONVERSION_NO_GUI_PROGRESS'='0' -e 'AUTOMATED_CONVERSION_NON_VIDEO_FILE_EXTENSIONS'='jpg jpeg bmp png gif txt nfo' -e 'AUTOMATED_CONVERSION_HANDBRAKE_CUSTOM_ARGS'='' -e 'AUTOMATED_CONVERSION_INSTALL_PKGS'='' -e 'AUTOMATED_CONVERSION_VIDEO_FILE_EXTENSIONS'='' -e 'AUTOMATED_CONVERSION_OVERWRITE_OUTPUT'='0' -p '7803:5800/tcp' -p '7903:5900/tcp' -v '/mnt/user/Media':'/storage':'ro' -v '/mnt/user0/Media/Handbrake_hotfolder/output/':'/output':'rw' -v '/mnt/user/Media/Handbrake_hotfolder/watch/':'/watch':'rw' -v '/mnt/cache/appdata/HandBrake':'/config':'rw' --device='/dev/dri' --cap-add=SYS_NICE --log-opt max-size=50m --log-opt max-file=1 'jlesage/handbrake'
-
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.
-
1
-
-
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:
-
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.
-
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?
-
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.
-
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
-
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:
- Added the extra parameter as dictated. I assume "binhex-delugevpn" is the VPN container name? If not, I don't know what is.
- Switched Network type to none
- 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?
-
Unfortunately that does not change anything. Using the IP of my Unraid server in lieu of "tower" still yields the same error message when I try to test my indexers in Jackett.
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 -
18 minutes ago, ryanclark21 said:
Here is the supervisord.log with the user/pass redacted. Although I'm unable to access the WebGUI, I know it's running in the background as one of the sites it's connected to shows that I'm still seeding. I will note that prior to the most recent update, I was able to access the WebGUI with the same settings.
2021-03-03 15:14:18.957400 [info] LAN_NETWORK defined as '192.168.1.0/24'
Yeah that looks like a successful start and all settings seems to be ok. Are you sure the LAN_NETWORK range is correct?
If it is, maybe it's a problem on the web browser end, try disabling ad blockers, clear the cache and/or try accessing deluge from a private window or different browser? -
1 hour ago, betaman said:
Anyone here using NZBgetVPN along with DelugeVPN? I’m using privoxy for Radarr/Sonarr/Lidarr etc thru DelugeVPN and I’m able to connect to my indexers and DelugeVPN through each docker (after putting my server address in the ignore list) but now NZBgetVPN isn’t able to connect since the update to DelugeVPN. I assume this issue is related to the one referenced prior about dockers “outside the VPN” communicating with dockers inside it but then again, I’m using privoxy so not sure it’s the same issue? Can anyone confirm? Bungy (docker creator for NZBgetVPN) is asking about my network LAN_IP setting but this hasn’t changed (ie UnRAID server is 192.168.1.71 and LAN_IP setting is 192.168.1.0/24).
There's a fix coming for this, see https://github.com/binhex/arch-delugevpn/issues/258
Although, if you want to run NzbGet through a VPN tunnel, an alternative is to use the normal binhex NzbGet container and bind it's network to the DelugeVPN container. See Q24 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
-
20 minutes ago, RollinDolan said:
-
Jackett (all these settings are from Jackett's web GUI)
- Server port: 9117
- Proxy type: HTTP
- Proxy URL: tower
- Proxy port: 8118
- Web GUI is accessible after update
-
All configured indexers fail after update. When I test them, I get one of two errors:
- "Exception (<indexer-name> Unexpected character encountered while parsing value: <. Path '', line 0, position 0.: Unexpected character encountered while parsing value: <. Path '', line 0, position 0."
- "Found no results while trying to browse this tracker"
It seems that my issue is Jackett? I can't access my indexers on Jackett, and so Radarr and Sonarr cannot use them either.
Yes, you need to get Jackett working first.
I don't use jacket via Proxy, so I'm just guessing here, but could you try using the IP of unraid, instead of "tower" for Proxy URL?
-
Jackett (all these settings are from Jackett's web GUI)
-
34 minutes ago, ryanclark21 said:
I seem to be having an issue with the latest update to DelugeVPN. When I start the new version, I'm able to access the WebGUI but all of my torrents have a Tracker Status Error: Host not found and there is no external IP indicated at the bottom. I'm not too familiar with the logs but this error seems to keep coming up:
...
2021-03-03 14:21:13,106 DEBG 'start-script' stdout output:
[info] DNS failure, creating file '/tmp/dnsfailure' to indicate failure...
I'm seeing this too, have reported it to Binhex on github and will patiently wait for a new image build.
39 minutes ago, ryanclark21 said:I attempted to roll back the update to the previous version, which appears successful and the above issues are gone but I'm no longer able to access the WebGUI. I'm not using privoxy and I'm at a loss for what I can try next. I did change the endpoint for PIA but that didn't resolve the issue either.
Thanks for any suggestions!
Could you post new supervisord.log from the older version? Don't forget to redact user names and passwords first.
[Support] binhex - NZBGet
in Docker Containers
Posted
This is a long-standing problem that no one has been able to find the root cause of.
The common workaround is to use User Scripts to restart the container on a schedule every night. There should be details on how to do this somewhere in this thread.
Sent from my iPhone using Tapatalk