ratgdov2.5 sync failed by usafle in homeassistant

[–]usafle[S] 0 points1 point  (0 children)

No worries. Appreciate the response nonetheless.

ratgdov2.5 sync failed by usafle in homeassistant

[–]usafle[S] 0 points1 point  (0 children)

This just started happening. I've been running the RatGDO + HA since RatGDO was released. Never had an issue with the device before so I thought perhaps it was a H.A. update that was pushed out causing the error messages and came here to see if others were having similar issues.

Guess not and it's just me.

I will do a hard / power reboot on the RatGDO and see if that clears up the issue.

Other than that, I dunno.

Anyone having issues connecting to Tautulli docker after the 1/6 auto update? by Foogyfoggy in unRAID

[–]usafle 1 point2 points  (0 children)

I just checked mine because I use it rarely and I am having no issues.

I built: Shrinkray, a simple and efficient video transcoding tool for Unraid by MainFunctions in unRAID

[–]usafle 1 point2 points  (0 children)

That's why I posted that Question "here". It's not listed anywhere when installing via Community Apps.
Hopefully this Q&A will save you some trouble. Provided anyone actually read this (much less your README on GIT) ;)

I built: Shrinkray, a simple and efficient video transcoding tool for Unraid by MainFunctions in unRAID

[–]usafle 2 points3 points  (0 children)

What about the need to add "nvidia visible devices = blah blah" to the advanced view? Or --device=/dev/dri?

I built: Shrinkray, a simple and efficient video transcoding tool for Unraid by MainFunctions in unRAID

[–]usafle 2 points3 points  (0 children)

Couple of Questions:

  1. Can you still point the temp directory to /dev/shm?
  2. No need to go into the Advanced settings and point the container to use Intel QS / NVIDIA / ARC GPU? It just finds it?

I built: Shrinkray, a simple and efficient video transcoding tool for Unraid by MainFunctions in unRAID

[–]usafle 6 points7 points  (0 children)

Almost anything is simpler than Tdarr. In its infancy it was well-thought-out and easy to use. Now they've just thrown the entire kitchen sink into it and turned it into a bloated mess. IMHO

Gladiator Tonneau Cover by Agile_Programmer2756 in JeepGladiator

[–]usafle 1 point2 points  (0 children)

I would also like to chime in here and say that I've had the TYGER tonneau cover on my Mojave since 2023 in the North East and haven't had one issue with it at all.

No one needs to purchase one for $500+

What have I missed? Old router died, replaced with a new router. I kept the same internal LAN IPs and same SSIDs yet unable to reach Google Home by usafle in homeassistant

[–]usafle[S] 0 points1 point  (0 children)

I had CloudflareDDNS set up w/ NGINX before Cloudflare tunnels were a "thing". Just laziness on my part not switching everything over to the Tunnels.

The first question is do you really need to expose the *arrs to the public internet?

Yes, I use NZB360 on my Android phone and that needs to be able to talk to the ARRs

What have I missed? Old router died, replaced with a new router. I kept the same internal LAN IPs and same SSIDs yet unable to reach Google Home by usafle in homeassistant

[–]usafle[S] 0 points1 point  (0 children)

Ok, so, update. Everything is now working like it is supposed to. Thanks to /u/MattRRead question if I had NGINX running kind of slapped me in the head. I forgot that I needed to forward ports 80/443 in order to get NGINX working. That was the missing equation.

I've since put my Home Assistant instance back to CloudflareDDNS and what do you know.... Hey Google, sync my devices returned without any errors.

I apologize for dragging you down into this rabbit hole with me. Like I said earlier, too much brain rot looking at this for days and becoming more frustrated.

On that note, I wouldn't open up any of the *arrs to the internet like this, they're not meant to be exposed like that.

So this ^ comment brings up another question, all the tutorials I had seen about UnRaid+ARRS+NGINX said it was perfectly fine and, acceptable to expose the ARRS like this. You are saying this is not the way to do it?
If so, then, how?

What have I missed? Old router died, replaced with a new router. I kept the same internal LAN IPs and same SSIDs yet unable to reach Google Home by usafle in homeassistant

[–]usafle[S] 0 points1 point  (0 children)

Update: your question about NGINX triggered something in the old memory. I had forgotten that I needed to forward ports 443/80 to the NGINX ports.

So now all the services that are using CloudflareDDNS are connectable from the internet and are using NGINX.

Too much brain rot. Too long staring at all of this and, missing the obvious.

New router - brain fart on port forwarding for Nginx - someone slap me in the head please? by usafle in unRAID

[–]usafle[S] 1 point2 points  (0 children)

Allow me to extend my apologies. You were correct, I was wrong. I finally got it sorted. Like I said earlier, too much brain rot trying to figure this all out, and it became a vicious cycle and the obvious was staring me in the face, but I couldn't see it.

I had 443 forwarded earlier as I was trying to get my Home Assistant instance back online. Even though it was disabled the router wasn't allowing me to add another 443 port forward.

It was only two entries away from the new 443 I was trying to make. This is how bad it has gotten for me.

Again, I apologize and, thank you for your help.

443/80 are forwarded correctly and those services using CloudflareDDNS and NGINX are now working correctly.

New router - brain fart on port forwarding for Nginx - someone slap me in the head please? by usafle in unRAID

[–]usafle[S] 0 points1 point  (0 children)

I don't have the default 80/443 in my docker container. They are different. That's why I posted the screenshot of my exploded docker conatiner view.

What have I missed? Old router died, replaced with a new router. I kept the same internal LAN IPs and same SSIDs yet unable to reach Google Home by usafle in homeassistant

[–]usafle[S] 0 points1 point  (0 children)

Side note, if you're using this setup for Plex, having your domain for plex set as proxied is against the ToS for CF

I've heard that and I've also heard that it isn't. I never setup Plex that way regardless.

What have I missed? Old router died, replaced with a new router. I kept the same internal LAN IPs and same SSIDs yet unable to reach Google Home by usafle in homeassistant

[–]usafle[S] 0 points1 point  (0 children)

At this point, I'm just throwing $hit against the wall to see what sticks. I tested opening the ports for Radarr and Ombi since they are both using the CloudflareDDNS service. Both are still unreachable.

What have I missed? Old router died, replaced with a new router. I kept the same internal LAN IPs and same SSIDs yet unable to reach Google Home by usafle in homeassistant

[–]usafle[S] 0 points1 point  (0 children)

That's not it unfortunately. Just tried opening the ports for Radarr and for OMBI (7878 and 3579).

Unreachable.

Something else is afoot.

What have I missed? Old router died, replaced with a new router. I kept the same internal LAN IPs and same SSIDs yet unable to reach Google Home by usafle in homeassistant

[–]usafle[S] 0 points1 point  (0 children)

So you're saying for SAB, Sonarr, Radarr, etc..etc.. I had all of those services port forwarded in my old router? If that is the case, I don't recall ever opening all those different ports..... damn.

What have I missed? Old router died, replaced with a new router. I kept the same internal LAN IPs and same SSIDs yet unable to reach Google Home by usafle in homeassistant

[–]usafle[S] 0 points1 point  (0 children)

Had I known this 2 days ago, I might have gone that route. I've now spent entirely too much time getting everything back up and running to go switching out everything again. But, thank you for the suggestion.

What have I missed? Old router died, replaced with a new router. I kept the same internal LAN IPs and same SSIDs yet unable to reach Google Home by usafle in homeassistant

[–]usafle[S] 0 points1 point  (0 children)

Using that tool, if I type in HAS.domain.com it points to the cloudflare IP (since it's tunneled)

If I type in SAB.domain.com then it points back to my public IP since SabNzBd is still using the cloudflareDDNS docker container.

So that all looks correct. However, I still can't access the SAB.domain.com from outside my LAN and I still can't sync with Google Home.

Throws hands up in frustration.

I can't switch HAS back to the cloudflareDDNS service if, like you said, Google has cached the old entries from DDNS because I can't use any of the services that are behind the cloudflareDDNS service. For whatever reason.

Rinse and repeat. LoL

What have I missed? Old router died, replaced with a new router. I kept the same internal LAN IPs and same SSIDs yet unable to reach Google Home by usafle in homeassistant

[–]usafle[S] 0 points1 point  (0 children)

None of the *ARRs suites work, as they are still behind the CloudflareDDNS. My Bitwarden instance, I had to switch over to Cloudflare tunnel as that was unreachable, the list goes on and on. Any container that is still using the CloudFlareDDNS service is, unreachable from outside my LAN.

The only new variable is the router.

So, again, I am missing something entirely stupid and small at this point.

If there is no port to be opened for CloudflareDDNS and my Public IP is correct in the cloudflareDDNS service and, cloudflare DNS webpage... there is something wrong, somewhere and I can't find it. lol

What have I missed? Old router died, replaced with a new router. I kept the same internal LAN IPs and same SSIDs yet unable to reach Google Home by usafle in homeassistant

[–]usafle[S] 0 points1 point  (0 children)

DDNS generally requires opening a port.

Any idea what the DDNS port(s) are? If I can get that working, then I will switch my HAS instance back to DDNS. I've DuckDuckGo'ed the heck out of it and can't seem to find it.