• Posts

  • Joined

  • Last visited

Everything posted by TrueImpulse

  1. You need to be using an endpoint that supports port forwarding or your speeds will be limited. Open up the Deluge log at startup, it lists all the endpoints that support port forwarding.
  2. Does anyone know why I'm getting this error? I have googled a bid and found similar errors but not this one and no direction on how to fix it. I'm trying to migrate Ombi over to mariadb.
  3. Has anyone else been having stability issues since the switch to V4? I keep having issues where you cant log in saying wrong password or requests don't go though. Only restating the container temporarily gets it going for maybe a day.
  4. Hey Everyone, My Nextcloud is currently stuck in an update stating only "update in progress" and I can't get it out. I saw in a post someone just used the backup made by the updater to restore their Nextcloud to the previous version. Could someone tell/link me how to do that? I know the location up the backup just not how to use it. Thanks, Edit: NVM I figured it out
  5. I'm having issues getting the Sonos integration working. After activating it this is all I get back from the logs, 2021-04-17 00:19:59,651 DEBG 'start-script' stdout output: 2021-04-17 00:19:59.650 INFO --- o.a.player.service.SonosService : No Sonos controller found 2021-04-17 00:19:59,651 DEBG 'start-script' stdout output: 2021-04-17 00:19:59.651 INFO --- o.a.player.service.SonosService : No Sonos controller found Anyone have any suggestions? I do have Airsonic running though Swag on its own subdomain but its accessible locally though http using the servers ip address and container port. For Sonos equipment I just have a couple of Ikea Sonos Bookshelf speakers.
  6. For me it was simply adding " :latest " to the end of the repository line. I'm also using wireguard/pia connecting to Toronto.
  7. I was having issues connecting to Canadian endpoints as well, same error in the logs. Was able to connect to the Bahamas just fine. Not sure which version I was running before (should have checked) but I added :lastest to the containers Repository field and after pulling down the image I'm able to connect to Toronto again.
  8. I keep having an issue where after I try to login via the cname I created I get a message that says "Unable to connect to Home Assistant." If I log in via the local IP it works fine. Im using the HA core docker and its network is set to host. I was able to get it working adding these lines to my nginx config file proxy_pass http://ip-address:8123; proxy_set_header Host $host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; Anyone see any issues with adding these line?
  9. Is there a way to delete cached data other then wiping the whole cache? I didn't notice the Twitch caching was a feature enabled by default. From what I understand this will cache any live streams you have watched on Twitch. I would like to delete all cached Twitch data that is taking up space. Thanks,
  10. Ok so I ended up grabbing the final proxy.conf file that was available for the letsencrypt docker and replaced the newest Swag one with it. Boom issue solved, Shinobi loads fine via the reverse proxy again. I opened and compared both config files to see what changed. Now I'm no coder but I can understand what most lines are meant to do (I know just enough to be dangerous). After disabling the line "proxy_set_header Upgrade $http_upgrade;" in the Swag proxy.conf file, Shinobi again was working normally though the reverse proxy. Hoping someone much smarter then me can take a look at both these config files and figure out why I was having an issue and if it would effect others. It did not appear to effect any of my other containers running reverse proxy. For now I'm running the final letsencrpyt proxy.conf to be safe. proxy_letsencrypt.conf proxy_swag.conf
  11. I have narrowed the issue I'm having to be https related. On the local network using the IP and port number of the container to pull up the webUI everything works fine. When I try using the subdomain URL I setup with the reverse proxy config file I made using the templet on page one I get a UI that wont fully load, whether I'm on my local network or not. Not sure how to fix it, was working fine for a while. I recently updated my letsencrypt container to Swag following spaceinvaderone's video he just posted. I had originally just changed the repository name (easy way) when I got the notification from Fix Common Problems about the move to Swag. I then updated to right way after watching the video. No idea if its related but its the only thing I have changed of my server since this issue started.
  12. Has anyone have issues just trying to get the webUI to load correctly? I installed Shinobi a few weeks ago and everything worked great at first but I've recently had issue where monitors would not load (black screen), or the camera image would stutter or have a lot of artifacts in the image. Like many others here I am running Reolink cameras, and when I have the issue in Shinobi I login to the cameras webUI to see if that has any issues and it never does. Now I regularly get a partially loading Shinobi webUI at times. My server is running deal Xeons with 32GB of DDR4 so I don't think its may hardware not keeping up. I'm currently only running two cameras but I want to add more soon. Just trying to see if this is a me thing or if others are having these issues. Also wondering what the e's are at the bottom of my log file. is starting ... \n 2020-10-10T15:39:01: PM2 log: Launching in no daemon mode 2020-10-10T15:39:01: PM2 log: App [Camera-App:0] starting in -fork mode- 2020-10-10T15:39:01: PM2 log: App [Cron-App:1] starting in -fork mode- 2020-10-10T15:39:01: PM2 log: App [Camera-App:0] online 2020-10-10T15:39:01: PM2 log: App [Cron-App:1] online No "ffbinaries". Continuing. Run "npm install ffbinaries" to get this static FFmpeg downloader. No "ffmpeg-static". Available Hardware Acceleration Methods : vdpau, vaapi Shinobi : cron.js started FFmpeg version : 4.2.4 Node.js version : v12.14.1 Shinobi : Web Server Listening on 8080 2020-10-10T15:39:02-04:00 Current Version : ba5743e3801ef240507cf75bdf909916fc51b104 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! This Install of Shinobi is NOT Activated !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 2020-10-10T15:39:04-04:00 This Install of Shinobi is NOT Activated !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 2020-10-10T15:39:04-04:00 : Checking Disk Used.. 2020-10-10T15:39:04-04:00 : /opt/shinobi/videos2/ : 0 2020-10-10T15:39:04-04:00 Starting Monitors... Please Wait... 2020-10-10T15:39:06-04:00 Orphaned Videos Found and Inserted : {"uI00WZV8xd":{"pBG6jtqUFy":0,"e9sJm2JdVE":0}} 2020-10-10T15:39:06-04:00 Shinobi is ready. e e
  13. Guinea pig reporting in. Switching to WireGuard was simple and worked flawlessly. I'm on the east coast and now getting 800Mbps into Montreal. Thanks for adding WireGuard to your containers. Had to buy you that beer for all the hard work you do on all your Unraid containers.
  14. Hey binhex, Is it possible to add multiple server addresses in the ovpn config file for PIA next gen servers like you implemented for PIA legacy?
  15. I'm sure your right. I know that 10.0.0* address are for private network IP schemes, I was kind of tired last night and I just went with it, sorry. This must mean that the container is disregarding all the 10.0.0.* addresses and using the Cloudflare I have in there. Still doesn't explain why its so slow resolving when I have the PIA addresses in there. I suppose the PIA DNS is having issue but I never had this problem on legacy. Dose anyone else have a browser pointed at their privoxy port and noticing very slow site resolves when using the default Name_Servers for a PIA setup?
  16. Since switching over to next gen PIA servers I have been seeing very slow website DNS resolves when using my browser that has its proxy settings pointed to the Deluge privoxy port. After some trouble shooting I decided to remove all the prefilled PIA DNS addresses from Name_Servers in the Deluge templet and only use the Cloudflare addressed. Doing this resolved me slow resolve issue. Turns out that PIA next gen has a new set of server addresses for it as well, link to them below. I added the new PIA DNS addresses to Name_Servers and everything is working normally again. Not sure if I missed this in binhex's instructions somewhere but I suggest that everyone who has moving over to PIA next gen also update the Name_Servers from PIA legacy to PIA nextgen addresses. Still not sure why I get slow resolves when the I have PIA DSN addresses listed in Name_Servers. Dose anyone else have a browser pointed at the privoxy port and seeing very slow site resolves?
  17. Just to confirm, are your speeds in megabits or megabytes. I just download an Ubuntu torrent at between 10-12 megabytes per second which is about 80-100 megabits per second. This is on a one gigabit connection using PIA connected to Canada. Deluge displays speeds in bytes (KiB/s-MiB/s) not bits. If 6-12 MiB/s is what your seeing displayed in the webUI that sounds right.
  18. I get they are moving over to next gen but all their update on their helpdesk site stated they were having problems with port forwarding on legacy servers and where "working to fix the issue". I think its now fair to say they had no intention to fix the issue. PIA is always trying to claim transparency but a move like this really doesn't give me any confidence. I'm sure port forwarding matters to a very small percentage of their customer base but its still a feature of their service that should work.
  19. I've been testing the beta image connecting to PIA Next Gen. While using a browser proxied though the container, getting a response from sites initially is slow, as if the DNS is hanging for a few of seconds. I can see the progress message state "waiting for proxy tunnel" displayed by the browser before the page loads. Happens even on sites that should be cached already. Once the site loads, subfolders and content load fine. I tested on a few servers with the same results.
  20. I have the same results, pulled the test image and connected into Canada, no problems. I see there are far more servers that support port forwarding on Next Gen. Hope this is the solution we've been waiting for. It seams PIA considers it low priority to get port forwarding working again on their legacy servers. Thank you binhex for all your efforts to find a work around to PIA's problems.
  21. For anyone trying to find PIA legacy servers that currently work with port forwarding I can confirm both Berlin and Spain will connect. You may have to allow several retries but once connected they do appear to be stable. I'm on the east coast and these are the closes servers I've been able to connect to.
  22. Hi, Having and issue (not sure if it even is an issue) with looking at the IP address when bashing into the deluge container. When I run the command "curl" though the deluge terminal I get back a public IPv6 address rather then the IPv4 address from PIA that the container is connected. In the web UI on the bottom right I can see PIA's IP address just not using terminal. The really strange part is that I don't have IPv6 enabled on my router and also have Unraid set to IPv4 only in network settings. Also when I run the same command in for example Radarr's terminal window I get my WAN IPv4 address even though in the Radarr seeings I have proxy enabled though Deluge. If I shut down Deluge anything that I have configured to proxy though it can no longer connect. When I proxy my browser though Deluge and do a IP leak test I get the IP address of the PIA server and no leaks. Again not sure if this is even a problem, just want to make sure I don't have any leak with Deluge or any other docker that is using it as a proxy.
  23. Hello, I'm fairly new to unraid (about 4 months) and love it so far but I'm having a small issue and I hope someone can shed light on it. When sharing a file in Nextcloud using the share via email app it seems that the file is being copied into the docker image before its sent. Unraid kept sending alerts of docker image usage at 95% while the file was being downloaded from my server. The file in question was about 8GB in size. It was also not coming from the Nextcloud share, I have an external storage folder added in Nextcloud and mapped in the docker with config type: Path, Host path: /mnt/user/public and Container path: /public. Hope someone has see this before become I'm lost.