Failed to resolve 'plex.tv'

[elliottmarter]

Describe the bug

I get the following in my logs

12:00:01 - ERROR - [PLEX API] Error (load user tokens): HTTPSConnectionPool(host='plex.tv', port=443): Max retries exceeded with url: /api/v2/user (Caused by NameResolutionError("HTTPSConnection(host='plex.tv', port=443): Failed to resolve 'plex.tv' ([Errno -5] No address associated with hostname)"))
12:00:01 - WARNING - [PLEX API] plex.tv unreachable - using cached user data only
12:00:02 - WARNING - [PLEX API] Watchlist data will be incomplete - array restore will be skipped

To Reproduce
Steps to reproduce the behavior:
Happens on its own during runs

Expected behavior
Should be able to reach plex.tv without error
However I am not sure why its trying to I dont want to move based on watchlist.
I have turned it off for my users but cannot turn it off for myself for some reason, the option is greyed out

Screenshots

Desktop (please complete the following information):

• OS: Unraid
• Browser: Chrome
• Version: v3.2.0

Smartphone (please complete the following information):
N/A

Additional context

[Brandon-Haney]

Thanks for the report, and the screenshot helped a lot. There were actually two separate things tangled up here, and digging into it turned up a real bug on our side. Fix is up in #198.

The greyed-out toggle

That one's on us for being unclear. The admin account's per-user toggles are locked on by design, so there's no way to turn watchlist off for yourself from that row. The switch you want is the global one at Settings > Cache > Enable Watchlist Caching. Turning that off disables watchlist for everyone, admin included, which sounds like what you're after.

I've added a tooltip on the locked toggle and a hint under the table pointing at it, since right now nothing tells you where to go.

The plex.tv errors

[Errno -5] No address associated with hostname means DNS came back empty, rather than plex.tv being slow or down. If their servers were struggling you'd normally see a timeout or a 5xx instead. So it's usually one of:

• DNS inside the container failing, which on Unraid is normally the host's DNS setting or something like Pi-hole restarting
• plex.tv's own DNS having a bad moment, which looks identical from your end

Worth ruling out the first since it's quick. From the Unraid terminal:

docker exec plexcache getent hosts plex.tv
docker exec plexcache cat /etc/resolv.conf

If the first comes back empty, it's local DNS. Adding a public resolver to the container usually sorts it, e.g. --dns=1.1.1.1 in Extra Parameters, or under dns: if you're on compose.

One detail I noticed: your failure is at 12:00:01, right as a scheduled run kicks off. If anything else on your network runs on the hour (Pi-hole gravity update, a DHCP renew, a backup job) that timing would line up.

Also worth a look at https://status.plex.tv. It's showing green overall, but the uptime bars for "Authentication and API server (plex.tv)" do have some amber days in them recently, so their end hasn't been completely clean either.

What we fixed regardless

Two things came out of this:

1. That first plex.tv call wasn't retrying. The rest of our plex.tv calls back off and try again a few times on connection errors, but this one didn't, so a brief DNS blip took out the whole run when a retry would have gotten through. It now uses the same retry helper as everything else.

2. The "array restore will be skipped" part was firing even with watchlist turned off entirely. That's not right. If you're not using watchlist, a plex.tv problem shouldn't stop your watched files going back to the array. This is probably the part that was actually costing you something, and it's the main fix in the PR.

Once that lands, turning off the global watchlist toggle will mean plex.tv trouble no longer touches your array restore at all. The DNS check above is still worth doing though, since a resolver that intermittently fails will cause other headaches.

[elliottmarter]

Thanks very much for the reply, only just got around to taking a look now

Still not quite sure whats causing the DNS failures, my container can successfully lookup plex.tv and DNS server settings seem fine.

root@marters-unraid:~# docker exec Plexcache-D getent hosts plex.tv
35.172.142.61 plex.tv
34.238.225.186 plex.tv
44.210.41.33 plex.tv

root@marters-unraid:~# docker exec Plexcache-D cat /etc/resolv.conf
nameserver 192.168.10.1
nameserver 8.8.8.8
nameserver 1.1.1.1

I also checked the watchlist setting but it seems to be toggled off already?

Also please let me know how I can update to test these changes I am currently on v3.2.0

and using ghcr.io/studionirin/plexcache-d:latest

Its not showing any newer versions via Unraid check for updates.

[Brandon-Haney]

On the DNS: [Errno -5] means your resolver answered but with no address records. glibc treats that as final, so it never falls through to 8.8.8.8 or 1.1.1.1 — those only get used on a timeout. A brief empty answer from 192.168.10.1 looks exactly like this while still testing fine by hand afterwards. The retry in the fix should ride over it.

On the watchlist toggle, you're reading it right and that's the bug. It's off, but in v3.2.0 a plex.tv failure still set the "watchlist data incomplete" flag, and that flag is what skips the array restore. Nothing for you to change.

To test it now, change your container's repository to:

ghcr.io/studionirin/plexcache-d:dev

That's a new rolling tag that tracks merged work, so both fixes are in it. :latest only moves when @StudioNirin cuts a release, so if you'd rather stay on stable, just wait for the next one.

One heads up: Unraid will show "not available" as the update status on :dev. That's a known quirk with how the manifest is published, not a problem with the image - force update/pull will work fine. Separate thing we're sorting.

[StudioNirin]

@Brandon-Haney
Which reminds me, is probably about time to roll up the latest updates into a 3.3. Will look into that tomorrow if possible

[elliottmarter]

Awesome, thanks very much.

I shall stick on latest for now and await 3.3 on that branch.