xxDeadbolt

Members
  • Posts

    160
  • Joined

  • Last visited

Everything posted by xxDeadbolt

  1. Had this a couple of times recently, too - but, as @wgstarks said, checking for updates usually sorts it out. Not sure what causes it
  2. 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.
  3. Just updated to latest, connected straight away on nextgen. Awesome work!
  4. 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.
  5. 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 😕
  6. 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
  7. 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 0 Tested 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 😧
  8. 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.
  9. 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!
  10. 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
  11. 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.
  12. 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.
  13. Yeah, got Berlin working again too, but I expect it'll go down again at some point 😆
  14. Ah I just assumed openvpn/wireguard would be included.
  15. I was also told by their chat support that port forwarding would be fully supported on next gen 😕 Edit:
  16. 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.
  17. 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!😂
  18. 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.
  19. 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.
  20. 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
  21. 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.
  22. 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
  23. 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!🤣)
  24. 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
  25. 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🤣)