PeterB

Hmmm ... I need a service which will allow me decent speed up and down AND let me access BBC from here in Philippines. I had a trial of unlocator (a smart DNS service?) which did enable access to BBC iPlayer, but the price of US$99 a year is a bit high! PIA don't appear to offer SmartDNS.

jmbrnt, I would be interested to hear what speeds you achieve once you have this setup working. I'm currently using the recommended PIA, but that doesn't enable me to access BBC iPlayer in the UK. I see NordVPN are promising a SmartDNS service later this year, which may allow access to the BBC site. However, I'm only interested if I can still get my 5MB/s torrent downloads (on a 50Mbps FTTH connection).

The '$', I'm sure, is a mistake.

Since stopping the radar and jacket containers, I've not seen transfers through the vpn tunnel fail. I will continue to monitor. Is it possible that there could be some untoward interaction between the CP, radar, jacket and delugevpn containers? Ooops, spoke too soon. Deluge transfers just dropped to zero briefly.

I've not changed anything at my end - no particular change in usage or configuration. What puzzles me is that the transfers through the tunnel cycle from zero, to max (50Mb/s) at something like ten minute intervals. When deluge transfers are at zero, my Kodi box, using privoxy, also cannot access themoviedb.org. Ah, I know something which has changed ... I noted that you'd put up a new version of CouchPotato, which seems to have fixed the problem with the IMDB interface, so I now have that container running alongside radar and jacket. I wonder whether those could be conflicting in some way? I had started using the privoxy service a week or two ago (for kodi) - but these problems weren't apparent until two days ago.

I attach the log. At startup, deluge connected and had uploads running at 2-3 MB/s and one slow download. By the end of the log, the transfers , both up and down had dropped to zero. DelugeVPN.log.zip A few minutes after I uploaded the log, transfers were running at 5+MB/s up and 120kB/s down. Apart from capturing the log, I had not made any changes to the container.

Something weird going on here. I enabled debug and then found that I could not connect, neither with the desktop client, nor to the web interface. Okay, I think that I didn't wait long enough - perhaps the startup is slower with debug enabled..

For the last day or two, my vpn connection has been repeatedly falling to zero transfer rate and returning to maximum rate. There is nothing in the delugevpn container log. It's not just deluge because, at the times the deluge transfer rate is zero, other connections via privoxy also go down. Other connections which don't go through the vpn tunnel are unaffected. Is The PIA Netherlands server playing up, or is my ISP messing with my vpn connection? Any thoughts how to identify the cause?

Hmmm .... just looked at the Docker page - it says that binhex-couchpotato image was created one year ago! I know that it was working properly just days ago.

My couchpotato docker appears to have lost the ability to access imdb. All the Box Office and Top 250 Movies displays ar grey and say "Unknown movie n/a". "Search & add new media" never finds anything. The pop up window opened by the CouchPotato bookmark never displays a movie in the drop down menu box. I've tried restarting the container several times, to no avail. What could be causing this?

See the FAQ : (referenced in Binhex's .sig).

Just upgraded to 6.40rc9f and the initial reboot failed. After a restart (with parity check) delugevpn fails to start. The log contains: Created by... ___. .__ .__ \_ |__ |__| ____ | |__ ____ ___ ___ | __ \| |/ \| | \_/ __ \\ \/ / | \_\ \ | | \ Y \ ___/ > < |___ /__|___| /___| /\___ >__/\_ \ \/ \/ \/ \/ \/ https://hub.docker.com/u/binhex/ 2017-09-23 19:59:08.657658 [info] Host is running unRAID 2017-09-23 19:59:08.877041 [info] System information Linux 2d6ab80a01be 4.12.14-unRAID #1 SMP PREEMPT Wed Sep 20 11:41:59 PDT 2017 x86_64 GNU/Linux 2017-09-23 19:59:08.964549 [info] PUID defined as '99' 2017-09-23 19:59:09.135634 [info] PGID defined as '100' 2017-09-23 19:59:09.687772 [info] UMASK defined as '000' 2017-09-23 19:59:09.757070 [info] Permissions already set for volume mappings 2017-09-23 19:59:09.868686 [info] VPN_ENABLED defined as 'yes' 2017-09-23 19:59:10.101475 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/Netherlands.ovpn dos2unix: converting file /config/openvpn/Netherlands.ovpn to Unix format... 2017-09-23 19:59:10.225978 [crit] VPN configuration file /config/openvpn/Netherlands.ovpn does not contain 'remote' line, showing contents of file before exit... It turns out that the .ovpn file had become empty (zero length)! Replaced the file, and all appears to be okay.

Do you mean uploading of public torrents, or are you referring specifically to private torrents? I'm on a 50Mb/s fibre connection and I regularly see 5+MB/s uploads through the Dutch PIA server - all public torrents. However, speeds are somewhat variable at the moment - the whole of Asia is suffering because two Pacific cables were damaged by storms, recently, off the coast of HongKong

What sorting/renaming do you want? For my purpose, simply moving the files to a different directory is sufficient.

Can't the facility, built into deluge, to move completed torrents, be used to automate this? The only problem I've found with using Deluge to move a file is that all torrenting activity stops while the file is being moved.

Well, they have a three day 'money back' promise, so I may give it a try sometime. However, I chatted with a support person yesterday and learned two things: 1) He couldn't tell me whether their certificates are compatible with OpenSSL 1.1 2) Their 'chameleon' doesn't foil the latest BBC iPlayer blocking ... but they are working on it. So, as far as I can tell, the only way to access iPlayer just now, is to use 'Unlocator'. Since unlocator works simply by changing dns servers, I presume that they are routing traffic through a proxy of some sort, and I'm not comfortable about doing that until I know more about exactly what they are doing.

Ooops, yes - I'd missed that. However, I'm not clear what Binhex has spotted in the log which indicates that it's a no-go. It all looks perfectly normal up to the UDP link remote. Then it just seems to hang, waiting 60 seconds for a timeout. Given that this is all a standard OpenVPN, it seems strange. I'm sure that Vypr does work with OpenVPN - perhaps this is another change in the latest OpenSSL? What I've done with other providers is to connect to the docker with bash. Ensure that the start script has stopped, then try starting OpenVPN manually and see what happens. I can compare that with the same procedure on my Linux Mint desktop (using OpenSSL 1.0).

Further research suggests that Vypr, with their 'Chameleon' software, should do all I need. Chameleon, supposedly, hides the VPN proxy, and allows ports to be configured for forwarding. Their .ovpn files contain: auth SHA256 cipher AES-256-CBC tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA so I hope that there will be no problem with the latest OpenSSL. However, their 'money back' offer only lasts for three days, so I need to make sure that I have sufficient time available to set up and test.

Interesting that I recently set up with PIA, using the Netherlands server, and can achieve near to a full 50Mbps up and down. I didn't do anything to open/forward ports. Experimenting with other VPN providers, my experience is that bandwidth is severely restricted. However, running speed tests is a little difficult within SE Asia at the moment, with a storm having knocked out some undersea cables close to HongKong. My problem with PIA is that they don't mask the fact that I'm using VPN and this prevents me accessing BBC iPlayer. I'm trying to find a VPN service which supports DelugeVPN and allows access to iPlayer. ExpressVPN seems not to allow port forwarding, which restricts Deluge. PureVPN uses old MD5 certificates which are no longer accepted by latest versions of OpenSSL in DelugeVPN. Does anyone have experience of VyprVPN or can recommend other VPN providers? This list of VPN providers who support port forwarding may be of interest. According to that, NordVPN does not allow port forwarding, so speeds will always be restricted.

I had that problem last week. Thing is, I'm not sure exactly what I did to get it working. Check your setting for LAN_NETWORK.

Thanks for the response. I have entered my password in Key3 (VPN_PASS). Where else do I have to define it? Okay, it seems that using a '$' as the first character of the password was upsetting things. I've changed the password and I now get further but, for some reason, twisted is reporting a 'CannotListenError'. I'm guessing that this might be something to do with two lines earlier in the log: [info] Deluge listening interface currently defined as 0.0.0.0 [info] Deluge listening interface will be changed to 10.24.10.6 Deluge appears to be running - I can access via the web gui but the deluge UI, running on my desktop machine, is unable to connect to the daemon. This was working fine until I enabled vpn. Later: Well, it seems to be working now, despite the messages still appearing in the log!

I originally used the nonVPN version of the deluge docker, but then moved to this delugevpn version, with vpn turned off. I have now created an account on PIA and have been attempting to configure the docker to use that. I have found nothing in this topic, nor on docker hub or github which describes the configuration page which the docker presents me with. I even found a you tube video with instructions on how to configure, but that also shows a different configuration screen to the one I have. My first attempt, after setting VPN_ENABLED = yes, reported a missing .ovpn file. After some research, I found that I have to download a .ovpn file from PIA, and place it in /config/openvpn, along with the .crt and .pem files. Having done this, the logfile shows the following error: 2017-08-30 00:59:30,968 DEBG 'start-script' stdout output: Wed Aug 30 00:59:30 2017 neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Auth Username:'. If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache. Wed Aug 30 00:59:30 2017 Exiting due to fatal error Here I am stuck. Having spent a couple of hours searching, I can find nothing which enlightens me. Full log attached. logfile

Apart from ensuring that inotify is set to yes in /config/minidlna.conf, what else is necessary to make sure that the database is updated after adding a file to the media directory? I've always relied on using minidlnad -R, but would like to get inotify working. max_user_watches is already set to 524288 [root@Tower /]# cat /proc/sys/fs/inotify/max_user_watches 524288 [root@Tower /]# I have less than 524288 files in the /media directory: [root@Tower /]# find /media -type f | wc -l 15411 [root@Tower /]# Adding a new file to the /media directory doesn't appear to get it added to the database.

Okay, that appears to have resolved the issue - many thanks.

Well, I guess if docker is killing the process with a signal 9, then the pid file wouldn't get removed. My photo frame is the only client of minidlna, so I turned it off, 'pkill'ed the minidlnad process (which removed the pid file), and restarted the container. I waited more than ten minutes before doing a restart on the container. When it started up again, the old pid file was still present and, of course, the minidlnad process was not running. With no client, what could be keeping the process busy? I have not seen a situation were (p)kill has failed to stop the minidlnad process cleanly, with deletion of the pid file. This suggests to me that either: 1) the system isn't waiting long enough for the Tini-initiated shutdown to complete or, more likely in my view: 2) Tini isn't actually doing what it's meant to do I see that tini is running with pid 1. [root@Tower /]# ps -eaf root 1 0 0 00:12 ? 00:00:00 /usr/bin/tini -- /bin/bash /root/init.sh root 7 1 1 00:12 ? 00:00:00 /usr/bin/python2 /usr/bin/supervisord -c /etc/supervisor.conf -n root 57 7 0 00:12 ? 00:00:00 /bin/bash /root/crond.sh root 61 57 0 00:12 ? 00:00:00 crond -n nobody 62 1 0 00:12 ? 00:00:00 /usr/bin/minidlnad -f /config/minidlna.conf root 63 0 0 00:12 ? 00:00:00 bash root 69 63 0 00:12 ? 00:00:00 ps -eaf [root@Tower /]# How could we prove whether tini is working correctly, or not? I can see evidence, in supervisord.log, of crond being stopped, and waiting for it to die, but see no evidence of minidlnad being stopped, but perhaps that is not logged in the same way - as a child process, for instance?: Created by... ___. .__ .__ \_ |__ |__| ____ | |__ ____ ___ ___ | __ \| |/ \| | \_/ __ \\ \/ / | \_\ \ | | \ Y \ ___/ > < |___ /__|___| /___| /\___ >__/\_ \ \/ \/ \/ \/ \/ https://hub.docker.com/u/binhex/ 2017-05-23 00:12:22.714187 [info] Host is running unRAID 2017-05-23 00:12:22.741692 [info] System information Linux Tower 4.9.28-unRAID #1 SMP PREEMPT Sun May 14 11:03:53 PDT 2017 x86_64 GNU/Linux 2017-05-23 00:12:22.800289 [info] PUID defined as '99' 2017-05-23 00:12:22.882640 [info] PGID defined as '100' 2017-05-23 00:12:23.168672 [info] UMASK defined as '000' 2017-05-23 00:12:23.218772 [info] Permissions already set for volume mappings 2017-05-23 00:12:23.256912 [info] SCAN_ON_BOOT defined as 'no' 2017-05-23 00:12:23.297819 [info] SCHEDULE_SCAN_DAYS defined as '06' 2017-05-23 00:12:23.327048 [info] SCHEDULE_SCAN_HOURS defined as '02' 2017-05-23 00:12:24,359 CRIT Set uid to user 0 2017-05-23 00:12:24,359 INFO Included extra file "/etc/supervisor/conf.d/minidlna.conf" during parsing 2017-05-23 00:12:24,376 INFO supervisord started with pid 7 2017-05-23 00:12:25,378 INFO spawned: 'start' with pid 56 2017-05-23 00:12:25,379 INFO spawned: 'crond' with pid 57 2017-05-23 00:12:26,003 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 47810346303928 for <Subprocess at 47810346306160 with name start in state STARTING> (stdout)> 2017-05-23 00:12:26,003 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 47810346306088 for <Subprocess at 47810346306160 with name start in state STARTING> (stderr)> 2017-05-23 00:12:26,003 INFO success: start entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2017-05-23 00:12:26,003 INFO exited: start (exit status 0; expected) 2017-05-23 00:12:26,003 DEBG received SIGCLD indicating a child quit 2017-05-23 00:12:27,004 INFO success: crond entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2017-05-23 00:22:11,142 WARN received SIGTERM indicating exit request 2017-05-23 00:22:11,155 DEBG killing crond (pid 57) with signal SIGTERM 2017-05-23 00:22:11,166 INFO waiting for crond to die 2017-05-23 00:22:12,167 DEBG fd 16 closed, stopped monitoring <POutputDispatcher at 47810345808600 for <Subprocess at 47810346306016 with name crond in state STOPPING> (stderr)> 2017-05-23 00:22:12,167 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 47810346305008 for <Subprocess at 47810346306016 with name crond in state STOPPING> (stdout)> 2017-05-23 00:22:12,167 INFO stopped: crond (terminated by SIGTERM) 2017-05-23 00:22:12,167 DEBG received SIGCLD indicating a child quit I note that if I (p)kill minidlna, then the following line appears at the end of the minidlna.log file: [2017/05/23 00:34:56] minidlna.c:154: warn: received signal 15, good-bye However, that line never appears when the container is stopped or restarted.