I need logs before this please. Hopefully what I am trying to check is there in your oldest log from that logs capture
I was after the logs for earlier to try and understand why a specific issue is showing up in the logs. Not directly related to the outage
the problem arose when the 04:23:12 check came in from Tautulli. The 04:11:12 check was ok
The 04:23:12 coincided with an EPG database optimization
Am I right in thinking that the change from 1 minute to 12 minutes reduced the frequency of the issue arising ?
change it from 12 minutes to 45 minutes and see if that makes a difference
Yes - the issue only affects the port number stored in plex.tv for your server. It is getting zeroized due to what appears to be a timing bug after an outage. I am hoping that this timing bug would not be encountered without the repeated refreshReachability Tautulli requests (or would be rare)
New zip attached - all “Plex Media Server”, + today’s up/down notifications from Tautulli.
PlexLogs.zip (2.4 MB)
You mention 04:23:12 - My first notification through Tautulli wasn’t until 05:11:13.
Q-1) Frequency over days?, or,
Q-2) frequency over single time once it occurred?
A-1) Seemingly “no”? As stated last week in the private discussion, this seems to occur haphazardly.
Here’s the occurrence pattern, and how many notifications I get in the entire day.
7/28 - 28
Adjustment to 12 minutes was on/about 7/20
7/19 - 20
7/17 - 24
7/16 - 22
A WHOLE MONTH, then …
6/14 - 10
6/8 - 6
6/6 - 6
6/4 - 6
A-2) The notifications seem to still occur twice an hour. I actually had the most ever this time.
MUCH too short a notice. I’m willing to go as high as 21 - slightly less than 3 times an hour.
I don’t even like THAT long a time, but for testing, I’m willing to do it.
I’ve just set it to 21 minutes.
There is an issue with the async reachability tests and it is not working. I have already flagged it to the development team
The new logs is a continuation of the same session. Once it goes wrong and a zero port is registered with plex.tv then recovery would either be a relaunch of Plex Media Server or going through disabling and re-enabling remote access - without any interference from Tautulli
jonny already explained that the alert does not get sent till after the 3rd failure that Tautulli detects - so that would explain the mismatch in what I said as the time it went wrong and the first notification
The development team will not give the issue any priority if the impact is because of a third party application using an interface and api that was not intended to be used in this way.
I am sorry I cannot help any further. As I said the issue has been raised. The severity of the problem and the impact to users will only be judged based on users that are not running the Tautulli remote access reachability checks
Just like to say - that it is possible that the bug is serious and has a big impact - but this needs to be proven to be the case without the Tautulli requests.
Thanks @sa2000 - Your time is appreciated.
] cynic mode on [
I’m reasonably sure I’ll see 10 great new niche features added to Plex that few true ‘daily users’ really asked for, and 2-3 more niche clients added during the time rather than older more common clients get updated or fixed.
Such is the way of Plex since it hit 0.09.0-ish.
] end cynic [
Well this is not the way to ask for a feature - by using an api that was intended for different scenario. As I said a refreshReachability will get the same result once the port number has been set to zero at plex.tv end. It will only change if the user goes through the steps of disabling and re-enabling remote access or possibly restarting the server - or some periodic action by Plex Media Server. The end point being used is there for plex.tv to use when the user configures remote access and enables it and the user would be on that settings screen.
There are other means for Tautulli to achieve what it wants to do. One example would be to request the machine identifier from your server via GET /identity and then use the identifier to lookup the non-local entry for that server within the resources.xml for which the end-point is already published in this support article https://support.plex.tv/articles/206721658-using-plex-tv-resources-information-to-troubleshoot-app-connections/ . From the resources.xml, Tautulli can get the url to use to reach the server through the WAN public IP.
Of course hitting plex.tv with such a request every minute from every server with Tautulli would be unacceptable and could be seen as a DDOS action - but doing it every 60 minutes may be ok - but the volume of servers doing it would need to be assessed by the Tautulli developers and perhaps negotiate with Plex to allow for high volume of requests which Plex may not have allowed for when sizing the plex.tv infrastructure.
As to features, beta 1.13.5.5291 which was released a few days ago brings in a feature that many users have been asking for and waiting for - Bind to specific interface only?
I should stress that if Tautulli wishes to hit a plex.tv endpoint periodically from all servers it manages then the developer should approach Plex Inc and ask if it is ok - or establish what volume Plex would deem acceptable
This is a publically available API on plex.tv. If Plex does not want the public to use that endpoint in a way that is not intended, then they should be applying some separate restrictions to it such as rate limiting. It is not the job of the user of the API to determine if something is intended or not. That is the job of the person designing the API. If something is publically available, then it will be used.
I have already address this in my private message to you, but it seems like you completely missed those points. Because you seem to be “throwing me under the bus” here, I am publicly posting my response to your private message for the record below. See “Re: “Using /api/resources”” and “Re: “Why not ping the server’s http://PUBLIC-IP:PORT from /api/resources instead of using /myplex/account?”” in the copy of the private message below.
Again, that is not how public APIs work. If this is unacceptable, then Plex should implement rate limiting. I have already offered to work with Plex on a solution/alternative to this issue. I even provided a suggestion in my private message but I have not received any feedback or response from the Plex team. See the last paragraph in the copy of the private message below.
You are a Plex Team member. You should have taken all this information to the Plex development team, which you said you have done. You have not provided me with a response from the development team, nor has anyone from the development team contacted me.
Copy of private message between @sa2000 and me on July 19, 2018 to July 20, 2018
3 Likes
@SwiftPanda16 I am waiting for staff to come back from holiday. Hoping to get you a response from Plex employee. However, my statement about the refreshReachability being inappropriate still holds and I am relaying back what was said by development that this endpoint was intended for use when a user goes through enabling/setting up remote access
With regards to resources.xml, i was not thinking of using the presence=x value but that you would hit each of the connection uri’s in the connections info for the server - you could test out local=0 ones sending out a request like GET /identity which is what a refreshReachability does. You could even try out both http and https routes and report back if server setting has preferred for secure connections.
The drawback of using refreshReachability is that if there is any glitch or the test fails at that moment, you would end up with the port info disappearing from plex.tv making it impossible for Plex clients to find a usable route to the server. The use of this api was not envisaged to be unattended but to be used by Plex Web with the user there in front of the screen
With regards to rate limiting requests, I would not think that you would want your users to have their use of Plex impacted and getting rate limiting errors simply because Tautulli wants to make so many requests. There should be a balance between real use of an interface and one use just to check if all is ok. You would not want the former impacted
I wasn’t asking for a feature. I’m simply using a monitoring app because, even though many methods for server and user monitoring were requested by server admins many years ago, a developer took it among themselves to use Plex API.
If a server goes down, one shouldn’t have to wait an hour to find out.
It’s too long.
And statements like this from Plex, devs, employees, or volunteers, are what help make me cynical.
As a SERVER, I believe that option should have existed within one year of the first Plex server release (if not first day)
I’ve seen people mentiong problems regarding the inability since 2013. (When I first came across Plex, about 3 years after it first came out)
7+ years later - that’s hell of a long time.
Back on topic -
I look forward to the true remote availability monitoring that the Plex team and Jonnywong16 come up with.
I’m just constantly repeating the same responses to you over and over again.
Okay, so please stop suggesting to everyone on a public forum that it is me that needs to reach out to Plex about this. It is up to the development team to respond.
To be completely frank with you, I don’t care if it’s “unacceptable” or “inappropriate” or “unintended”. Plex has a public accessible API and I’m using it publically. It is not my job, nor any other developer using the Plex API, to know if an API endpoint is intended to be used or not, especially when there is no API documentation avilable.
Re-quoting what I already said above:
By the way, refreshReachability is hit every time you visit the server settings page. Nothing to do with setting up remote access. So one could just refresh that page once every minute to check if their remote access is working and it would have the exact same effect as Tautulli (actually probably an even larger impact because there are a lot more things loading on that page).
You seem to have missed it for a third time, so I’m going to copy and paste my response here directly. Understand why I am not using the method you have just described. If Plex forces my hand because they are unwilling to provide a better alternative and this becomes the only option, then I will consider it.
So the development team should make it only available from the settings page, and not available unattended.
I’m not suggesting that rate limiting is the correct solution. That was merely an example of how someone designing an API can implement restrictions on the API to prevent unintended usage. If Plex does decide that it should to be rate limited, then obviously Tautulli would be designed to stay within the limit so that the user is not impacted. I have already provided my suggestion, which once again for the third time, I will directly copy and paste it as a response here because I am still unsure if you actually read it or not.
6 Likes
Maybe my issue is different but I use Tautulli and my Plex remote access keeps saying it is not available. I know it is available and does work outside my LAN but I get a message about being an indirect connection and stream quality could be impacted.
If I stop using Tautulli will my Remote access start working again? Right now it shows connected and like others have said within 5-10 seconds it says its not anymore.
FWIW, my system has been much more stable since I turned off the “remote connection” monitoring in Tautulli. It’s still running and reporting on when the server itself goes down as well as tracking my stats and sending out the “new content” e-mail.
Now that I think about it, I wonder if part of the problem might be a collision between the “server up/down” monitoring and the “remote connection” monitoring? Not enough of a coder to know, but it might be a possibility.
Yes - we do have a bug but the likelihood of hitting it is much reduced if the continuous monitoring using Tautulli is not done
It was working fine and then it just started having issues again. Is the bug on the server patch or on the connections between servers and plex.tv?
When I am on the server itself and attempt to open I get 
If you are not running Tautulli continuous remote access testing through the refreshReachability api, I would like to see the logs covering the time when remote access was lost and switched to the Plex Relay indirect route. If logs do not go back to that time, please look into increasing number of log files using the advanced setting ‘LogNumFiles’ mentioned on this support article https://support.plex.tv/articles/201105343-advanced-hidden-server-settings/
