This seems a bit excessive, no?
Updated… in the first 12 hours of today my Plex Media Server has made over 108,000 DNS requests and over 100,000 of them are to tmsapi.plex.tv.
Operations and Engineering have been working on this for about two weeks now.
What geographic region is the server in? It will help us with another related issue being tracked
That having been said. 30,000 requests means that’ there were 30,000 items to look up. Does this match the library size?
Region: So Cal, Palm Springs area.
I have under 500 items across all of my libraries.
Do you have an active Tuner and EPG in use?
But it is initialized for your zipcode, meaning it has loaded the Program Guide but there are no recordings scheduled? (which that screen indicates)
If true, Please collect the the log files (settings - server - help - download logs), attach them to this post .
I will alert the team member who’s handling this issue of your logs and report
Before I attach a log file, can anyone download it or only Plex team members?
There are a couple recordings scheduled, but we don’t use that feature heavily.
You can PM it to me, with the link to this thread (and thread title written in it please). Doing so will guarantee it’s completely private. I personally will forward it to other team members.
Just got an update from the team members.
- Engineering has the correction in hand and completing final testing.
- It’s about to go to QA and then m QUICKLY to Plex Pass
- I’ve been advised to let you know not to bother researching given the documentation already in hand
Sounds good, hopefully the release notes will provide some detail regarding the root-cause and the fix.
By the way, log files were went before I saw your last post; disregard if not needed.
@ChuckPA My interest in root-cause and fix details is based on @sa2000’s comment here.
Being on this side of the issue as a network engineer, my concern is what cached data refers to in that context; i.e. is it the DNS cache, or the media metadata? Hopefully the latter…
Please see my PM back to you.
sa2000 and I were chatting about this case in our area. This is why my instructions to you now match his 
@rideekulous said:
@ChuckPA My interest in root-cause and fix details is based on @sa2000’s comment here.Being on this side of the issue as a network engineer, my concern is what cached data refers to in that context; i.e. is it the DNS cache, or the media metadata? Hopefully the latter…
It’s application cache data.
PMS uses Object - Source caching, where “source” is a URL whether PMS internal or external. External requires a DNS query. External queries should be cached. This is where the failure occurred. Each individual internal query was generating a hard external query as if caching had been completely disabled.
So my PMS is running in an Ubuntu 16.04.4 LTS server (VM on my ESXi host at home)… it seems PMS ignoring the server’s local DNS cache and forcing a lookup for all of these redundant artist info (metadata) queries.
Bug-ception? 
#MustGoDeeper
Apparently out of the box, Ubuntu doesn’t maintain a DNS cache (as a windows host does)… becoming more clear now.
Time to let you guys do your thing and refocus on my work projects. :s
Thanks again for all of the information.
Most Linux DNS is “Forwarder”. If you have a 'smart box" (e.g. pfSense) this isn’t a problem >:)
Yeah, since I now know that my Ubuntu VM isn’t caching, I understand why my DNS server (Pi-hole) was getting bombarded with DNS lookups.
Plex Media Server version 1.12.3.4947 has just been released as beta
It has a fix for caching bug where the cache was not correctly checked before making EPG requests to tmsapi.plex.tv. With this fix, the volume of requests should reduce significantly - 75% reduction has been observed.
See Release Note http://forums.plex.tv/discussion/comment/1650553/#Comment_1650553
- (DVR) HTTP request cache should properly check for file expiration when requesting celeb/series data. (#8405)
