Server Version#: 1.40.0.7998
Player Version#:
<If providing server logs please do NOT turn on verbose logging, only debug logging should be enabled>
Copying this over from my Reddit post:
Attaching my server logs from the latest incident of matching failing. It’s happened I think three times today. Always resolved with a reboot for a short period of time.
Within the last couple weeks a problem has crept up. On a fresh boot, matching works just fine. However, after a period of time (few hours? less than a day), plex stops being able to match. new additions will fail to match and selecting “match…” from the dropdown menu brings up the dialog but is unable to find any matches. On a reboot, this problem goes away for a bit but then returns necessitating a reboot.
My setuo. Ubuntu Server Docker linuxserver image plex:latest with VERSION: latest as env var. plex is on a macvlan so it has direct presence on network with a static IP
Again, everything was working without these issues until a couple weeks ago.
Anyone else experience something similar?
Edit: Currently on server version 1.40.0.7998 and it is still happening
Not the OP. Having the same problem as far as I can tell. I also replied to the OP’s reddit post.
Plex on offical Docker Container within Unraid 6.12.8 - which is current and recent. So recent as to muddy the troubleshooting picture. Yesterday nothing would update meta data. I yak shaved for a bit and didn’t get very far. Walked away from the problem for about an hour. Returned to it. Optimized Database (not rebuilt libraries) and refreshed the new content’s metadata. It showed up. Huzzah.
Added something today, and adjusted the file system layout (had an extra folder) - no metadata. Show isn’t showing matched, fixing match gives no results to pick from and does not automatch. Shows in question have tmdbs/tvdb tags - have worked for months. I have previously matched shows that now show no match and thus no ‘refresh metadata’ option.
External or DNS Network connectivity/query issues seem to be the culprit - the icon for my user is missing on the servers web interface but shows up in the top corner of the same interface. Machine is happily serving content to local clients (I have no remote clients).
The same HTTP -6 error shows up for the MetadataAgent. The docker host can make successful DNS lookups, and I see no blocks (or even queries - which is a concern) on my pihole when doing any metadata related operations. I do see successful queries when issuing an nslookup from the unraid itself - which is in host-mode. Indeed plex.tv is my top permitted domain in this pihole log cycle. Disabling blocking to be certian changes nothing.
I do not see any cause or reason to think the network issue in question is local as a result of my tests, but I’ve not started to sniff the network traffic or put watch-rules on the firewall.
Happy to provide whatever other details might be helpful.
Yes, it can. There are also a dozen other docker services running on that server without issue. Network issues also does not explain why it’s immediately fixed after restarting the container only to fail later.
Trying to make sure our problems are aligned as I chew on this. It feels like we have more in common than not but I wanted to ask:
Are you seeing agent: tv.plex.agents.none in your logs (looks like in Plex Media Server.log as well? I’m seeing that as well as the HTTP -6 ERRORS. I also see none replaced by ‘series’ and ‘music’ etc but the ones that are failing - ‘none’
I’ve not been able to get anywhere by restarting the container.
Editing to add the following errors seem interrelated.
MetadataAgentPostProcessor: failed to find agent for identifier tv.plex.agents.series
MyPlex: Updating device connections failed, retrying…
Could not resolve host: plex.tv - for all manner of errors. Which makes sense for this behaviour if it can’t. Question is why not given the docker host can - and this container is in host mode with the same address. I even see the lookups succeeding on pihole for the domain.
[Req#941f01/MetadataAgent/tv.plex.agents.series] MetadataAgent: match request failed, provider returned -6 error ()
Just had a weird one that tried to look for a show in a different library too and got no such file or directory in return.
Library section 2 (TV Shows) will be updated because of a change in "/data/TVShows/The Six Million Dollar Man (1974) {tvdb-77294}{imdb-tt0071054}[tvdb-77294][imdb-tt0071054]/Season 03"
Feb 21, 2024 18:31:58.221 [124482161224504] WARN - Error scanning directory, we'll skip and continue: boost::filesystem::last_write_time: No such file or directory [system:2]: "/data/Anime/Shows/The Six Million Dollar Man (1974) {tvdb-77294}{imdb-tt0071054}[tvdb-77294][imdb-tt0071054]"
I have a library at ./TVShows and a library at ./Anime/Shows. I have no idea why it would even consider looking in Anime for this item…
I docker exec’d into the plex container’s terminal and tried some pings. Hit all of my DNS servers and Google’s. successfully. Went back and tried match again and it failed to show any results. Rebooted container and is fixed for now.
I did a bunch more digging and fighting with this.
At roughly the same time as my update for this plex version pihole also had a version update due to a security concern in the core code. I don’t know if this update triggered this new behaviour or the plex update or just bad timing.
But an nslookup of plex.tv against the pihole would return the correct ip set but would also need to fall back to TCP vs. UDP - ;; Truncated, retrying in TCP mode. - using a different DNS server Google/Cloudflare whatever - did not cause a need to truncate. This may be due to DNSSEC issues (as that is I believe what the pihole patch/update was related to). Possibly with the patch to pihole’s update/patch for the security issue, possible with the plex.tv domain’s DNSSEC issues - I’ve not investigated that far, but would seem less likely. Why plex is unhappy with the returned value over TCP vs. UDP is also a puzzle. If this turns out to be the fix.
As a hopefully temporary work around I’ve removed the pihole from the dns path for my docker host (unraid). This is a pihole running on baremetal and not another docker on the unraid device to forstall any concerns about docker->docker networking issues.
As of this moment my user icons are back, scanning/metadata is appearing at the expected speed, and plex can check for current version - and confirm it is on it.
So unless this breaks again - in short order I’m feeling fairly positive that this change has had a meaningful effect.
I also deleted agents/plugin bundles for anime and for audiobooks which I now need to decide if I wish to undo. They were certainly out of date as it was.
Hopefully this helps someone and I’m not editting/posting an update to this with an update to it all being broken and my optimism misplaced.
I’ll add in this edit that the edge router on this network is a pfsense firewall - as that could be stepping into the picture, even MTU could.
If I’m reading these comments correctly, I’m experiencing basically the same thing. It will match metadata for a little while after a fresh restart, but then suddenly just stop shortly after. This is a clean install of the latest version of the server, so I’m not sure what’s going on.
there might be something to this. I don’t have this level of experience to know what I’m looking for when digging into it, but I did change my Plex server containers DNS settings to google instead of my internal pi-holes. It seems to be ok for now. I still don’t understand why it’s fine for a while after a reboot though.
For clarity, I use pihole as my local DNS resolver with Unbound as it’s upstream link.
It may work for a while due to the caching nature of DNS. Some reports of this generalized behaviour hint at it working when the pihole has looked it up itself and thus has is locally cached, but the first time plex asks and it isn’t in cache anymore - fails.
Some more breadcrumbs I used to get to my conculsion:
I’ve not been able to see exactly where on my particular set of these aspects I can adjust things other than the upstream DNS change. To compare my enviroment to the above reddit link’s mention of pfsense for example - I’m not using the DNS features of pfsense the same way as the commentor (it is a forwarder only in the odd chance that all the other wheels fall off) - not to mention the time that has passed and the versions/patches.
I suspect it was the pihole update in response to the security issue. I’ve not personally tried to report this byproduct to them - given it was a change made at around the same time for me - I assume you also did the offered update around the same period.
The reddit link noted above seemed to linked it to .tv in general - though plex is certainly a propular .tv domain and I suspect lots of people that run plex also run pihole and other homelab servers - including pfsense etc. But the data in that link is over a year old.
Knowing if you did that update at around the same time would be helpful. But part of me is waiting for the upgrade to pihole 6 or a less rushed patch and revisiting the issue then. However, why the result that returns correctly even with the fallback to TCP vs. UDP doesn’t seem to make plex-server/scanner/etc happy is beyond me. All the log indicates is network failure from our end user perspective.
@KritPlex you are a champion sir, thank you. Turned sdns off on my piholes and everything is working normally again. Not ideal, but I would rather be going through my dns path with sdns disabled than use my provider’s.
