strike

also add udp to the remote line so it looks like this: "remote gw1.atl3.slickvpn.com 443 udp" Edit: please post a new debug log if it doesn't work. From the log you posted earlier there were issues determining the protocol and yeah you might wanna try the IP insted of the hostname "remote 23.239.17.108 443 udp" You may also have to remove/comment this line after adding udp to the remote line "proto udp"

Can you try changing the port from 8888 to 443 too?

If you edit the atlanta ovpn file and replace "gw1.atl3.slickvpn.com" with "23.239.17.108" can you reach the webui then? Stop the container first of course. You seem to have some trouble with name resolution.

I would definitely recommend trying different endpoint's and check which is better. I would take a guess and say France or Germany is performing better. Just a guess of course

Btw have you tried reducing the number of connections in deluge? It could be that your router is having trouble with that many connections. If so it should be affecting other clients as well, and you said other clients work fine. Shot in the dark, but hey, it's worth a shot. The thing that's puzzling me is you said it's only local machines that are affected. And pinging any remote IP's is normal..

Could be. I know PIA says they don't do any throttling, but it's certainly possible. Which endpoint are you using?

Yeah, I know. I wasn't quoting you, my reply was for @sirelewop14 I'm afraid I don't know what's causing your issue

What segmentation fault are you seeing actually? Also that log isn't very helpful. Try enabling debug logging in the emby setting under "logs". You should post your unraid diagnostic too. Tools->Diagnostics

I'll just quote myself from the post a bit further up. This applies in your case as well: Also try different endpoints as this can make the biggest difference. The NL endpoint was long considered to be the fastest one but since they dropped that from the port forwarding list I don't know anymore. And I'm not using PIA anymore so I can't really test, I was a long time user tho. I would try France or Germany maybe. You can also see Q5 in this post for more tips: https://lime-technology.com/forums/topic/44108-support-binhex-general/?do=findComment&comment=433613

The docker container works fine. Have you tried turning on/off or adjusting QoS on your router? Also if you're on 6.5 stable or 6.5.1 RC 1 try upgrading to the latest RC. There have been many issues related to docker and LT has downgraded the docker version in the latest RC. Do you have many torrents in deluge? Deluge doesn't work that well with lots of torrents, there have been many reports of that. Maybe that's your issue. Although I've never seen anyone report huge ping times because of that.

If you haven't done so already, limit your upload to about 80% of what your connection can handle. If you don't put a cap on your upload it will "overload" your network causing lower download speed and higher ping. This should be done regardless of the client you're using.

@dp917 Please follow the procedure in this link: https://lime-technology.com/forums/topic/44108-support-binhex-general/?tab=comments#comment-435831

Which vpn provider do you have? To able to seed your vpn provider must support port forwarding, if they don't you won't be able to seed. If they do support it you need to open a port and put that port in deluge settings. Except if you have PIA then the port forwarding is done automatically for you, you just need to enable strict port forwarding in the container settings

Ssh plugin works, idk about denyhosts tho since I haven't used it in a while.

This is not how you delete the docker image which contains all the docker container. You go to settings->docker then you set enable docker to no, Enable advanced view in the right top corner, then delete the docker image. Set enable docker to yes will recreate the docker image. All of your containers are now gone and you need to install them through CA's previous apps. Click on apps, then hover over the green hamburger menu on the left, click previous app. Then you install all the containers you had again, no need to change anything as all the settings/mappings are preserved.

If you don't delete the appdata and install all the containers using community application previous apps the configuration gets preserved. I don't remember if the torrents gets preserved, but I'm 90% sure that they do. I checked the appdata folder and there's a folder named "state" where all the torrents and their state gets stored. So as long as you don't delete the appdata I think you should be good.

I had this issue once myself, I ended up deleting the docker image, recreating it and pulling down all the dockers again. This solved it for me and only takes 5 min. I don't know what causes it but I've seen several people having this issue.

PIA's API for port forwarding is apparently down for some endpoints. Switch to the NL endpoint which should be working.

Are you on 6.5.0/6.5.1 rc1 by any chance? There is a kernel bug which is affecting some users (including me) in this version. It can cause instability and even crashes some docker containers. If you get call traces in your syslog like this one, it's likely your issue: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 Mar 22 00:23:48 Tower kernel: IP: tcp_push+0x4e/0xee Mar 22 00:23:48 Tower kernel: PGD 8000000101df7067 P4D 8000000101df7067 PUD 101e37067 PMD 0 Mar 22 00:23:48 Tower kernel: Oops: 0002 [#4] PREEMPT SMP PTI Mar 22 00:23:48 Tower kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables ip6table_filter ip6_tables vhost_net vhost tap tun veth xt_nat macvlan ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat xfs nfsd lockd grace sunrpc md_mod e1000e ptp pps_core ipmi_ssif sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel aes_x86_64 isci crypto_simd glue_helper cryptd i2c_i801 libsas i2c_core hid_logitech_hidpp scsi_transport_sas intel_cstate intel_uncore ahci libahci intel_rapl_perf hid_logitech_dj aacraid wmi ipmi_si button [last unloaded: pps_core] Mar 22 00:23:48 Tower kernel: CPU: 0 PID: 27975 Comm: privoxy Tainted: G D 4.14.28-unRAID #1 Mar 22 00:23:48 Tower kernel: Hardware name: Supermicro X9SRL-F/X9SRL-F, BIOS 3.2 01/16/2015 Mar 22 00:23:48 Tower kernel: task: ffff8808c3fbe200 task.stack: ffffc90009d14000 Mar 22 00:23:48 Tower kernel: RIP: 0010:tcp_push+0x4e/0xee Mar 22 00:23:48 Tower kernel: RSP: 0018:ffffc90009d17d30 EFLAGS: 00010246 Mar 22 00:23:48 Tower kernel: RAX: 0000000000000000 RBX: 00000000000005a8 RCX: 0000000000000001 Mar 22 00:23:48 Tower kernel: RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff88074db4c800 Mar 22 00:23:48 Tower kernel: RBP: ffff8808c3fbeb20 R08: 000000000000fe88 R09: 0000000000000000 Mar 22 00:23:48 Tower kernel: R10: ffff88074db4c958 R11: 0000000000000000 R12: ffff88074db4c800 Mar 22 00:23:48 Tower kernel: R13: 0000000000000000 R14: ffff88070d1cc400 R15: 00000000ffffffe0 Mar 22 00:23:48 Tower kernel: FS: 00001459eef37700(0000) GS:ffff88103f200000(0000) knlGS:0000000000000000 Mar 22 00:23:48 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 22 00:23:48 Tower kernel: CR2: 0000000000000038 CR3: 0000000101f2c004 CR4: 00000000000626f0 Mar 22 00:23:48 Tower kernel: Call Trace: Mar 22 00:23:48 Tower kernel: tcp_sendmsg_locked+0xa53/0xbac Mar 22 00:23:48 Tower kernel: tcp_sendmsg+0x23/0x35 Mar 22 00:23:48 Tower kernel: sock_sendmsg+0x14/0x1e Mar 22 00:23:48 Tower kernel: sock_write_iter+0x70/0x86 Mar 22 00:23:48 Tower kernel: __vfs_write+0xe1/0x109 Mar 22 00:23:48 Tower kernel: vfs_write+0xc3/0x166 Mar 22 00:23:48 Tower kernel: SyS_write+0x48/0x81 Mar 22 00:23:48 Tower kernel: do_syscall_64+0x6d/0xfe Mar 22 00:23:48 Tower kernel: entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Mar 22 00:23:48 Tower kernel: RIP: 0033:0x1459f01a58bb Mar 22 00:23:48 Tower kernel: RSP: 002b:00001459eef332d0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 Mar 22 00:23:48 Tower kernel: RAX: ffffffffffffffda RBX: 00001459eef333f0 RCX: 00001459f01a58bb Mar 22 00:23:48 Tower kernel: RDX: 0000000000001387 RSI: 00001459eef333f0 RDI: 0000000000000007 Mar 22 00:23:48 Tower kernel: RBP: 0000000000001387 R08: 0000000000000000 R09: 0000000000000000 Mar 22 00:23:48 Tower kernel: R10: 0000000000000000 R11: 0000000000000293 R12: 00001459eef333f0 Mar 22 00:23:48 Tower kernel: R13: 0000000000000000 R14: 00000000004eefab R15: 0000000000000001 Mar 22 00:23:48 Tower kernel: Code: d0 75 02 31 c0 41 89 f3 41 81 e3 00 80 00 00 74 1a 44 8b 8f 68 05 00 00 41 d1 e9 44 2b 8f 6c 06 00 00 44 03 8f 74 06 00 00 79 10 <80> 48 38 08 8b 8f 6c 06 00 00 89 8f 74 06 00 00 40 80 e6 01 74 Mar 22 00:23:48 Tower kernel: RIP: tcp_push+0x4e/0xee RSP: ffffc90009d17d30 Mar 22 00:23:48 Tower kernel: CR2: 0000000000000038 Mar 22 00:23:48 Tower kernel: ---[ end trace aac96a4aaa1a6d5c ]--- See this thread:

The VPN_REMOTE parameter is not used anymore. The container pulls all the info from the .ovpn file. Thus the instruction to only use one ovpn file and delete all others. Put the file you want to use in the openvpn folder along with the crt/pem files. If you want to change endpoint simply replace the ovpn file with another one and restart the container

Ok, then I'll just go ahead and take a look at the v2. Thanks for the awesome work you do btw!

I've never had this issue before, but I think this is what happened last night. When I woke up I saw in the log it was still attempting to do the backup 7 hrs after it started (saw this form the timestamp), just line after line of emby files was showing up in the log. Docker service was not back up, and I couldn't get it to start. Did a reboot and after the second time of disabling/enabling the docker service, it came back up. According to my e-mail the backup had succeeded, but that's clearly not what happened. I should also mention that this is my first backup with 6.5.0. Is this the same issue others have been reporting? If so maybe I should just install the v2. Of course, I forgot to download diagnostic before I rebooted..

You can also try to add http2 to your main server block config which will load pages that have a lot of images a bit faster

When you say added, did you actually add it to your config or did you just uncomment it the default nginx.conf.? Because if you added it you're probably missing two lines: gzip on; gzip_disable "msie6"; Without the first line it won't work. That's why I told you to just uncomment the lines in the default nginx.conf because it's all there but most of it is commented out. If you haven't removed it. You can also add image/svg+xml To the last line. Worked like a charm for me, images and everything loads instantly.

@Nickglott, @lespaul In your nginx.conf uncomment these lines: gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; Made my emby a lot faster, the sign in page is still slow but once you sign in it's faster. Also remember if you have configured your disks to spin down, there will be a delay to spin up any disk that's not spinning.