xxDeadbolt
-
Posts
160 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by xxDeadbolt
-
-
Hey - decided to give this container another go as I got sick of my slow speeds on your DelugeVPN option. It's either PIA related, or something I'm doing as everyone else isn't having slow speeds... I seem to have this sorted now on rTorrentVPN, & have a quick question.
The below image is my ratio group settings... I'm looking for torrents to stop & have the data removed when the ratio hits 1.0-1.1, would this suggest it's accurate? I've stuck in a test download and the "UL target" is usually double the torrent size, no matter what the ratios are set to.
Strike that - done another couple of tests, and they seem to all be deleting themselves within the 1.0-1.1 ratio, no matter what shows in the 'UL Target' or 'UL Remaining'. Another wee thing, though, I just want to double check, but would amending the '#throttle.global_up.max_rate.set_kb = 0' to something like '350' here:
change this value:
Seems straight forward enough, but just making sure before I edit anything, as I have been known to "misunderstand" wordings before haha.
-
1 hour ago, binhex said:
OK Testing is now over, i am satisfied that PIA Next-Gen network using OpenVPN is working well enough to push this to production, so the changes have now been included in the 'latest' tagged image, if you have been using the 'test' tagged image then please drop ':test' from the repository name and click on apply to pick up the latest again.
If you want to switch from current to next-gen then please generate a new ovpn file using the following procedure:-
Note:- The new image will still support current (or legacy) PIA network for now, so you can use either, dictated to by the ovpn file.
Just updated to latest, connected straight away on nextgen. Awesome work!
-
2
-
-
1 hour ago, Druiff said:
So i am using the test release as well.
Trying to connect to Amsterdam takes about 18-ish minutes.
And after connect the speed doesnt get above 400-600kb/s. Any tips what I can try to improve this?edit:
As soon as the docker is running... My internet connection gets unstable. Not sure why, but pinging to 8.8.8.8 or 1.1.1.1 often times out. and even a ping to my modem/router averages to 500ms response time. Might the docker/vpn overwhelm my modem or/and do I have a shitty modem?
(this problem existed before PIA changed anything. But back then it only happend after a week or so.. and a restart fixed it.Sounds like similar thing to me - I'm getting those speeds as well (I should be roughly 10-13MB/s) - Probably not the router itself, I use the Asus RT-AC86U, but I don't get those ping results, though.
-
1
-
-
5 hours ago, binhex said:
i have always seen significantly better performance with rtorrent/rutorrent (my vpn app of choice) than i have with deluge, dont ask me why but there you go, have a look at the following link Q6 for tips and tricks on performance improvements:-
https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
Just tried your rTorrent container & tested a radarr addition, got speeds at the level I'd expect when downloading (roughly 8-10Mib/s, which is a far cry from the 600Kib/s I was getting in Deluge😂). I'll have a look at setting that up properly to use for the time being, & keep Deluge on for nextgen testing for now.
Edit: spoke too soon - seem to have gone back to having a global DL rate of ~600Kib/s. Must be PIA, but still annoying why others are showing much faster rates in line with their connection speed than I seem to be able to achieve when it's specifically through unraid torrent dockers 😕
-
1
-
-
4 minutes ago, cardo said:
I’m seeing slow performance as well, but I suspect it’s on the PIA side. Strangely, binhex’s rTorrent VPN docker using Mullvad without forwarding working I can get 82-85MB/sec on my gigabit connection, but the same torrent with next gen in DelugeVPN won’t get above 22-24MB/sec and that’s using the high performance options with the ItConfig plugin.
Not so sure mine is strictly on the PIA end - I was only getting around the 600Kib/s mark on the old gen as well... but only in delugevpn. I'd expect to see some different between using my Windows rig and using unraid - but not going from 600Kib/s > 13Mb/s lol
-
Connected now, after a bunch of retries, to Frankfurt.
Seemed to have a few logs of this; am I right in thinking this is when PIA aren't permitting a reallocation?
[warn] Unable to successfully download PIA json to generate token from URL 'https://212.102.57.65/authv3/generateToken' [info] 2 retries left [info] Retrying in 10 secs...This is the one I seen most, not sure what it is, or refers to, but most people seem to be seeing it:
2020-09-25 10:07:16,021 DEBG 'start-script' stdout output: parse error: Invalid numeric literal at line 4, column 0Tested using an Ubuntu image download... and I'm still getting only around 600-800Kib/s in download speed. Cannot for the life of me figure out why I'm not getting any faster than that. Same image, connected with PIA Windows app (same location endpoint on nextgen) on gaming rig is getting ~12-13Mb/s 😧
-
1 minute ago, chris_netsmart said:
Reading back through the posts. And before u go ahead and do this. Is it as easyer as.
Download the new opvn files.
Unzip and choose you endpoint
And copy over the endpoint and cerf.
If so then i will try it later once i get home. And post the results
Remember and change the 'Repository' part to show':test:, too:
I'm struggling to get connected. Tried Berlin for the last 90mins or so (let it cycle for about 30mins, stopped, gave it 20mins or so before another attempt) & about to try another endpoint, so will update when I've tried that.
-
Just updated, working fine now. I did have to remove Montreal from the config code, as in the logs it seemed to stick at the "attempting to get a dynamically assigned port" part, but not sure what that would be down to (I assume PIA or me!). After that, I reordered them to try Spain first, which failed, then Berlin which worked. Appreciate the work, binhex!
-
The past few mornings, I've had 2 errors showing in the system health. One is about not being able to connect to Deluge, but there's been nothing wrong with it & Radarr hasn't had any errors with it. The other is below, not sure if this is something on my end or within Sonarr.
Proxy Health Check failed: Error getting response stream (ReadDoneAsync2): ReceiveFailure: 'http://services.sonarr.tv/v1/ping' System.Net.WebException: Error getting response stream (ReadDoneAsync2): ReceiveFailure: 'http://services.sonarr.tv/v1/ping' ---> System.Net.WebException: Error getting response stream (ReadDoneAsync2): ReceiveFailure at System.Net.WebResponseStream.InitReadAsync (System.Threading.CancellationToken cancellationToken) [0x000e6] in /build/mono/src/mono/mcs/class/System/System.Net/WebResponseStream.cs:458 at System.Net.WebOperation.Run () [0x0018f] in /build/mono/src/mono/mcs/class/System/System.Net/WebOperation.cs:283 at System.Net.WebCompletionSource`1[T].WaitForCompletion () [0x0008e] in /build/mono/src/mono/mcs/class/System/System.Net/WebCompletionSource.cs:111 at System.Net.HttpWebRequest.RunWithTimeoutWorker[T] (System.Threading.Tasks.Task`1[TResult] workerTask, System.Int32 timeout, System.Action abort, System.Func`1[TResult] aborted, System.Threading.CancellationTokenSource cts) [0x000e8] in /build/mono/src/mono/mcs/class/System/System.Net/HttpWebRequest.cs:956 at System.Net.HttpWebRequest.GetResponse () [0x0000f] in /build/mono/src/mono/mcs/class/System/System.Net/HttpWebRequest.cs:1218 at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x0011b] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\Dispatchers\ManagedHttpDispatcher.cs:82 --- End of inner exception stack trace --- at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x001ca] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\Dispatchers\ManagedHttpDispatcher.cs:113 at NzbDrone.Common.Http.Dispatchers.FallbackHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x000b5] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\Dispatchers\FallbackHttpDispatcher.cs:53 at NzbDrone.Common.Http.HttpClient.ExecuteRequest (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookieContainer) [0x0007e] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\HttpClient.cs:121 at NzbDrone.Common.Http.HttpClient.Execute (NzbDrone.Common.Http.HttpRequest request) [0x00008] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\HttpClient.cs:57 at NzbDrone.Core.HealthCheck.Checks.ProxyCheck.Check () [0x00065] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Core\HealthCheck\Checks\ProxyCheck.cs:46 -
That's fair enough, no point doing that when it'll only cause stability issues with this. Would hope longer term, PIA sort the issues and continue to support port forwarding on OpenVPN with the 'nextgen' side of things.
-
46 minutes ago, binhex said:
post on reddit by PIA support staff:-
I'm the first to admit that I have no idea the complexity that would be involved (other than VERY) in you doing this, but is it a possibility to change from OpenVPN to Wireguard for this docker container? Obviously, I know it wouldn't be any time soon, just wondering how much of a pain it'd be.
-
Yeah, got Berlin working again too, but I expect it'll go down again at some point 😆
-
Just now, binhex said:
it does work.....if you want to use their app, if you want native openvpn/wireguard client then you are out of luck.
Ah I just assumed openvpn/wireguard would be included.
-
I was also told by their chat support that port forwarding would be fully supported on next gen 😕
Edit:
-
1
-
1
-
-
Had issues again during the night, like the above - turned port forwarding off for now & it'as been fine. I've not noticed any slower speeds, I seem to be capped at around 600 or 700KiB/s in total. Not sure why, but this is the same speed I was getting before, so I'll keep it disabled.
Edited for clarity: My connection shouldn't reflect those download speeds, should be way higher.
-
Cheers, @binhex! I've found PIA's support to be somewhat useless, but I've not been anywhere near as helpful in the info I gave them, so that may be a reflection on the questions asked & limited details I've been able to provide!😂
-
15 hours ago, NVS1 said:
I know you didn't speak directly to my post, but I looked at that and saw similar errors in my logs... turns out it was the VPN provider (PIA)... Not sure what's going on, but the CA locations don't appear to support port forwarding anymore, and their france location must be having locations. Resorted to de-berlin, and everything is back online now.
I'm using CA Vancouver just now & don't have any issues with port forwarding. I think with PIA doing their 'next gen' changes, as a few people here have mentioned, it's causing some instability over a bunch of locations.
-
OK, thanks. Pretty sure my containers always all stop when the parity check is running, but I'll keep an eye on it... I might just be seeing unrelated events and connecting them lol.
-
Was this recently? Hasn't been an issue for me. I'll change the time it's set to update & hopefully that'll resolve it when it clashes with a parity check
-
That's weird then, it's definitely stock unraid I'm using... but I think I've figured it out.
I've got CA auto update installed, and it's set to check/update at midnight, which is also when the monthly parity check is scheduled to start. Would this overlap be an issue with it all happening at same time? Not sure why it would cause my containers to be stopped though.
-
Yeah, all the containers were stopped & (as my check has just now finished), they've all started automatically again. I just thought this was normal behaviour
-
Had a quick look in the forum, but haven't seen anything here or in the unraid documentation.
I run a bunch of containers, but one I'd like kept enabled during the scheduled parity check is pi-hole, since it affects my whole network during as everything gets disabled. I don't mind about any others, as they can wait, & I get that anything which downloads/adds new data to the array could affects the parity. However, is it absolutely necessary to have all dockers disabled during a scheduled parity check? Can the check still be done if I manually enable pi-hole?
(My check is almost done, but I don't want to try it in case it starts it over!🤣) -
On 8/28/2020 at 3:01 AM, dasz said:
A few days ago I started having lots of torrents throwing "Connection timed out" errors. It cycles through trackers seemingly randomly: sometimes all torrents from a single tracker have the error, sometimes it's torrents from 4-5 different trackers. "Update tracker" option doesn't help.
I'm using deluge 2.0.3 with AirVPN; I tried with several different servers but it doesn't make a difference. Incoming port is forwarded through the VPN and checks out as open.
EDIT: It was DNS related. Not sure which server(s) is causing issues, but changing the NAME_SERVERS variable to use only Cloudflare's 1.1.1.1 DNS fixed the problem.
On this variable, should it be left at default with all the name servers listed already in it? Or can you select one or two to use?
Think there are 7 or 8 by default, wondering if this would potentially be the cause of my slow download speeds.
EDIT: Nevermind, I've just realised what the NS addresses all are
-
4 minutes ago, huladaddy said:
Can you please explain this in more detail. Thanks.
In the DelugeVPN webui, click 'Preferences' > 'Network'. The incoming port here should match the forwarded port number you've been assigned by AirVPN.
If you're configured for PIA, I believe this is automatically done for you.
(I'm not sure if the incoming address was specific to me, so I obscured it🤣)
[Support] binhex - Sonarr
in Docker Containers
Posted
Had this a couple of times recently, too - but, as @wgstarks said, checking for updates usually sorts it out. Not sure what causes it