obviously this type of thing is unavoidable if bits of the internet go down that plex rely on but it’s the poor programming choices about how to repetitively and an increasingly generate requests for the same URL over and over again, flooding the local network with unnecessary traffic. Below is just 1 minute of request
I’m also having trouble with pubsub.
Specifically when scanning a Music library.
Here is a short summary of what I have done so far in troubleshooting:
Verified the server is signed in with a valid Plex account and Lifetime Plex Pass.
Verified Internet connectivity from the Plex server.
Verified the Plex server can reach plex.tv and retrieve /identity, /media/providers, and account information.
Verified all Plex Music provider services (Metadata, EyeQ/Gracenote, AcoustID, LyricFind, Songkick) report online.
Recreated the Music library.
Created a brand-new empty Music library pointing at a test folder.
Restarted Plex Media Server.
Reproduced the issue on two independent Plex servers:
Windows 11 (original production server)
Arch Linux (Docker) (new production server)
Bypassed Pi-hole completely by configuring the Windows server to use Cloudflare (1.1.1.1) and Google (8.8.8.8) directly.
Also tested Cloudflare DNS over HTTPS (DoH) on the Windows server.
No DNS configuration changed the behaviour.
Movies and TV libraries continue to scan and refresh normally.
Here is an excerpt from one of my logs when attempting to scan:
Jul 23 20:xx:xx DEBUG - Request: GET /identity
Jul 23 20:xx:xx DEBUG - Request completed: 200 OK (Signed-in)
Jul 23 20:xx:xx DEBUG - Request: GET /media/providers
Jul 23 20:xx:xx DEBUG - Request completed: 200 OK (Signed-in)
Jul 23 20:xx:xx DEBUG - Request: GET /library/sections/6/refresh
Jul 23 20:xx:xx WARN - Need to be signed in and connected to the Internet to refresh a plex music library.
Jul 23 20:xx:xx DEBUG - Completed: 503 GET /library/sections/6/refresh
I asked our ops team and there is an issue with pubsub but should be fixed soon.
As far as the status page it looks like it stayed green because it was not completely down but they are looking into how to get that to be more accurate.
Also seeing this issue on a macOS server, same version (1.43.3.10828). My pubsub connections fail the exact same way described above: connects successfully, then errors out and never completes.
One additional data point that might help narrow it down: I tried removing my server from authorized devices and re-linking it fresh. The device-linking (PIN-based) process fails in the identical pattern. It connects fine but never actually completes. I tried this right after a clean server restart, twice, with the same result both times. So it seems like it’s not just pubsub; the account and device-linking side appears to be affected too.
For anyone else worried about their data during this: local library access and playback have been completely unaffected the whole time. I’ve confirmed mine is all still intact.
