PLEX FAILURE to Connect / Stay connected to the Server WHERE IT RESIDES

General Discussions
1

This has been an ongoing problem with ALL versions of PMS for the past two years and has NOT BEEN RESOLVED to date.
Plex does not connect / stay connected to the Server WHERE IT RESIDES!
I’m sure that this has been encountered by anyone who has MORE THAN ONE Server running PMS as I see it happening ON A DAILY BASIS.
I actually have three system where PMS is installed to Serve the media content on each of these servers. I connect to them through the Web interface (using Google Chrome) with the SPECIFIC IP ADDRESS for each of these Servers; however, Plex is very “confused” about which Server to connect to or even to STAY connected to…
I could be in the middle of checking / updating content when Plex decides to “go out the Window” and connect to a DIFFERENT Server*, other than the one WHICH RESIDES ON THE SERVER TO WHICH IT WAS CONNECTED! Or, after sitting inactive and supposedly operational, when attended to again, IS NO LONGER CONNECTED TO THE SERVER WHERE IT RESIDES!
So why does it NOT connect / stay connected to the Server where IT IS INSTALLED?
(In deference to another machine?)
I’m HABITUALLY having to restart PMS in order to get it reconnected to the Server WHERE IT IS ACTUALLY RUNNING / INSTALLED (as specified by IP), or in extreme cases, have at times had to logoff / log back on to the Plex account.
This has become such a BIG PROBLEM that yesterday, Plex TRASHED an installation BECAUSE IT WAS SO CONFUSED, once again, that after a glitch (failure to properly refresh metadata for a given movie) and being restarted, IT CONNECTED TO THE WRONG SYSTEM and began running through a setup procedure - presenting libraries to be displayed, etc.
Due to the fact that is ONCE AGAIN, DID NOT CONNECT TO THE SERVER WHERE IT WAS RESIDENT and “choose” a different server installation, when Plex was run subsequently, it said the the Server to which IT SHOULD HAVE BEEN CONNECTED was “not available” and continually (unsuccessfully) attempted to reconnect to the Server WHERE IT DID NOT RESIDE.
In other words, IT WOULD NO LONGER CONNECT TO THE VERY SERVER WHERE THE INSTALLATION WAS ACTUALLY RUNNING!
(Beyond BAD, it’s grotesque to think the programming is SO dysfunctional as to create such a problem.)
Was FINALLY able to recover operability by connecting to an “unclaimed and insecure server”, the one WHERE IT RESIDES. Connecting to the “uncalimed and insecure server” caused Plex to run through a setup procedure (again), this time when it was done, my previous Server SETTINGS had been altered and had to be reset (apparently returned to default settings).
Yea, this is a bug report - A VERY BIG BUG as those of you with more than one server know.
If anyone has an idea how to circumvent this bad programming, please let me know. As I say, my resolve has been to have to do a restart of the PMS docker in order to get it to connect properly (to the system where it resides).
Lacking that, obviously, the programming has to be fixed in order for it to operate properly.

*the dysfunction described at this point usually occurs while navigating from one library to another at which time Plex ‘stops responding’, doesn’t present the library content, then upon a refresh of the browser page IS CONNECTED TO A DIFFERENT SERVER.
(At which point, I have to do a restart of the PMS docker to get Plex functional again.)

2

Would you be kind enough to fill in some details?

  1. Primary distro for the hosts
  2. LAN IP setups (Are they RFC-1918 compliant?)
  3. Are the containers running in NAT or HOST networking mode
  4. Are there any VPNs involved?
  5. How many containers/servers are we talking about? (it looks like you have duplicates)
  6. Do you have any which run on the native host?
  7. How much is WiFi and how much is wired?
3

Hi Chuck,

Sounds like you’re ready to tackle this one. Sticky wicket, what?

All PMS installations on running on unRAID (Slackware); 2 systems with Kernel v4.14.49 (the ‘old’ system and auxiliary) and 1 system with Kernel v4.19.41). That makes for three systems and three ‘containers’. (The ones getting ‘confused’ as to which server they are connect to… which beats the hell out of me; how can they NOT know the system they are installed / running on?
I highly suspicion in this case that the problem may relate to the “devices” that are connected through Plex’s server account - the one that has to be logged-on to.)
I’ve found that the ‘confusion’ can be resolved by restarting the container, which happens just about every time I use PMS.

LAN IP’s are RFC-1918 compliant as provided by Internet Connection Sharing (Windows 10), the ONLY system that is wireless, with it and all other systems (on the back-end) being wired on the local network. The wireless internet connection is NOT set to automatically connect, so if the wireless connection (to the internet) is lost, I immediately know about it. That system is also not allowed to “sleep”, so connection is constant. Upon any disconnect, or if I have to reboot the Windows 10 system for some reason, I will disable sharing and re-enable it as I’ve found that doing so insures IP connection with all the ‘back-end’ systems.

All of the PMS installations are running in “host” mode, so whatever the IP of the machine, they are operating on the same. And, a VPN is used on these back-end systems as well as with the browser that connects to them (by their IP). NO VPN is enabled on the Windows system itself (other than through the browser, Google Chrome), otherwise communications with the back-end systems is disrupted.

Think that’s got it covered. If you need any further information, let me know.

Thanks,
Cary

4

Thanks Cary,

I did take a look into what Plex.tv sees.

I might have found the problem but need you to confirm.

Plex.tv is reporting:

  1. “Tower” @ 192.168.137.67
  2. “Tower” @ 192.168.137.55
  3. “Tower” @ 192.168.137.18
  4. “Tower” @ 192.168.137.76
  5. “Headless” @ 172.117.0.1, 192.168.122.1 (the virt br adapter), 192.168.137.195

If this is correct then the problem is obvious.

  1. Plex/web will display the Friendly name of the server (no IP shown)
  2. You have four servers with the same Friendly name.

The solution is to,

  1. Shutdown all the containers (servers) in host “Tower”
  2. Go to Settings - Authorized Devices - Server
  3. Remove ALL “Tower” entries.
  4. Sign out of Plex.tv (important)
  5. For each container on “Tower”
    a. Start one “Tower” container up
    b. Connect to it by IP or “Tower” name presented.
    c. Settings - Server - General - Show Advanced
    d. Give it a new UNIQUE name.
    e. Save the change
    f. Sign out of the browser (upper right)
    g. Shut down the container
    h. Go back to step a above and repeat for the next container

Repeat A->H above until all PMS servers have unique names.

Now you can start, see, and manage all without conflicting names anywhere.

How did this happen?

By default, PMS uses the hostname as the default “FriendlyName” unless you override that suggested name. It does not check for conflict when doing so.

5

Yo no me puedo conectar a mi server porque sale un error de conexion para el exterior, y creo debe ser por el proveedor de internet que seguro tiene algun bloqueo de ip y no deja salir al exterior

6

@Fernado_Florez

Crea un nuevo hilo para tu problema.
En ese hilo, proporcione el ZIP de los registros DEBUG que lo captura.

En el futuro, no se apropie del hilo de otra persona.

7

Nope, that’s not the case, Chuck.
There are no systems on IP’s 55, 67, and 18.
The “Tower” system is on IP 76 and it is the only system named Tower, has one (PMS) container and is the ONLY system that has a “Friendly name” (in PMS) of “Tower”.
All of the other entries (devices) are old news; up to a year old from what I’m looking at.
At this point, I haven’t touched the “authorized devices” since we’re in the ‘middle’ of this, but it looks like some ‘clean-up’ is needed.
AND, the problem continues.
I see no “authorized device” entry for “Headless” (system name and friendly name of the ‘old’ system) and, I fired-up a new server system which has yet to be put in production just to check its configuration. Once again, its server name, “Nameless”, coincides with the ‘friendly name’ used in its PMS installation. Along with “Headless”, it does not appear as an authorized device either. HOWEVER, since starting the PMS container on Nameless, the PMS installation running on Headless SAID IT WAS NOW CONNECTED TO NAMELESS - absolutely, it appeared as “Headless” in PMS before I started checking the configuration of all the systems.
Maybe even more interesting is the fact that IT IS IMPOSSIBLE for it to be connected to the server installation on Nameless as I stopped PMS on it right after checking its configuration - I have to assume that it was at that time that “Headless” BECAME “Nameless” (saying it was connected there). And then, just now when I went to the Server connection drop-down in the top-righthand corner of the PMS GUI (knowing that Nameless wasn’t even online) and opened the PMS Server name drop-down , it ‘changed’ to Rootless, which is specified to be “nearby”, it also had an entry for “Tower” as being “indirect”.
Selecting Tower showed the PMS contents of the Tower system.
Reverting the selection to Rootless actually shows (as it did before) the contents of Headless, and upon restarting the PMS container on Headless, it still says it’s connected to Rootless (which has its own PMS installation and is running), but PMS on Headless is (still) showing the contents of Headless.
I believe it is just assuming the name of Rootless, the most recent authorized device, despite the fact that its “friendly name” (as configured in Headless’s PMS installation) absolutely is designated to be “Headless”.
So, we still have a mish-mash as to what server PMS says it’s connected to and I think this confirms my suspicion that it is related to the “authorized devices”. It is failing to show, or make an entry for the server’s (PMS server’s) friendly name as it should be and the PMS installation on whatever computer is then ‘grabbing’ the authorized device entry created for an entirely different computer; DESPITE THE FACT THAT THE “FRIENDLY NAMES” DON’T EVEN MATCH.
I also have to wonder why an authorized device entry wasn’t created for Nameless.
It probably wasn’t created for Headless, because Headless has now ‘assumed’ the authorized device created for (by) Rootless.

Bottom line - doesn’t seem to be a problem (configuration issue) on this end.
At least, that’s what proved to be the case from running this little ‘exercise’.
My big concern is the havoc this scenario reeked on a system due to this “mis-match”.
(as detailed in the post)
I’m also pretty sure that if I’m experience the difficulty, users running more than one system are encountering the same to one degree or another…
Where do you want to go from here?

I think the questions that need to be answered are:

  1. Why is an authorized device entry not being made for a device that has a different ‘friendly name’ than any other authorized device?

  2. How is a device with a different friendly name allowed to use the authorized device entry created by a device with an entirely different name - the source of the ‘mis-match’, probably precipitated by the failure of an entry being made for a new device (device with a new, different device name)?

8

I would very much like to know that you’ve got the names of the servers cleaned up from the Plex.tv perspective.

To share with you the exact report I get from asking Plex.tv,

The user has 6 servers: Tower Tower Tower Tower Rootless Tower

From left to right:

  1. Tower – not seen in 5 months
  2. Tower – not seen in 6 months
  3. Tower – not seen in 5 months
  4. Tower – not seen in about a year
  5. Rootless - About an hour ago
  6. Tower – About day ago.

This confirms two active servers and 4 dead server entries.
The dead entries will throw Plex/web for a loop.

Please do go to https://app.plex.tv/destkop
From there → Settings - Authorized Devices (Left corner)
Now select the ‘Server’ dropdown where it shows ‘All’.

When you do, you’ll see something like mine.

Screenshot from 2020-09-24 00-46-07
Screenshot from 2020-09-24 00-46-071324×378 133 KB

For those dead server entries – Click the red X and “REMOVE” them.

Screenshot from 2020-09-24 00-48-44
Screenshot from 2020-09-24 00-48-44518×325 41.5 KB

When you’re done, you should only see the two active servers.

Now please go back to your server(s) and see what shows up.

Is this now less confusing?

9

Chuck,

I cleaned-up the account entries - removed the old (duplicated) devices.
You missed an important point from my previous dissertation - I have THREE active devices and absolutely, it is the Plex account / authorized devices that are ‘screwing the pooch’.
The Headless system at this point was STILL saying “Rootless”; logoff and logon made no difference. I checked the “friendly name” and it had been CHANGED! (to Rootless)
This should NEVER happen - the settings in the software should DICTATE, not the authorized device entry that it has NOW ‘assumed’.

Changed the friendly name back to “Headless” (I know that this was the case from the previous ‘exercise’ where I had checked the friendly names of all the systems.) And then, I “claimed” what became specified as an ‘unsecured’ server.
When I did this, the name of the authorized device that was “Rootless” BECAME NAMED “Headless”. (As I had mentioned before, “Rootless” was the most current authorized device entry created and that the Headless system NEVER MADE ITS OWN by name).
Now, I agree that the “friendly name” usage is the way to go as IP addresses can and do change for the same device (computer) from one boot to another, BUT we now have a computer system that is CURRENTLY ACTIVE, RUNNING PMS AND LOGGED ON (Rootless) whose “authorized device” that it created by its ‘friendly name’ HAS JUST BEEN USURPED by a computer of a DIFFERENT IP (both active AT THE SAME TIME) WITH A DIFFERENT “FRIENDLY NAME”.

Why is any such thing being allowed to happen?

A further inspection of the system whose setup got “hosed” (per original post) by this grotesque “mismatching” is displaying some peculiar characteristics that I don’t know what to make of…
On the side panel that displays the list of (pinned) Libraries, I selected “More” at the bottom.
Instead of just displaying ITS list of Libraries on that PMS server (Tower) it was first listing ALL OF THE LIBRARIES ON THE HEADLESS SYSTEM (under a named reference to that system with the Library list of that system BEFORE ITS OWN Library list (those of the Tower system).
I don’t understand why another system’s Library list should even appear here.

I logged off from my Plex account on the Headless system and the display of another system’s libraries changed to that of “Rootless” by name, with a list of Libraries once again preceding those of the Tower system itself. TOTALLY BIZARRE.

Also, I logged off of PMS on the “Rootless” system. Its Library list that was appearing on the Tower system remained.

What do you make of all this?

10

When you initially created these systems, especially the ones where settings and names are becoming “mixed”, did you copy configurations, directories, or settings from one to another? Or perhaps even clone the entire container/virtual machine/storage?

1 Like
11

@attidudinal

Volts raises the next valid point.

How much of what you have is cloned (literal copy — including Preferences.xml) of the other?

I ask because of right now, I see two servers.
The user has 2 servers: Headless Tower

1 Like
12

Absolutely, all apps, incl. PMS
(more follows in next response)

13

I’ve read enough scifi to know that when somebody is cloned, there’s always a disagreement over who is the original. :slight_smile: :smiley: :stuck_out_tongue: Hijinks ensue. “What, you aren’t my husband?” and “I prefer the clone, anyway.” Always hilarious.

There are identifiers in Preferences.xml. If you have two systems with the same identifiers, this is expected behavior.

I believe that it is adequate to erase those ID keys, and that they will be generated fresh on launch. Look for MachineIdentifier and friends. I don’t know EXACTLY which of the IDs need to be removed - if you wait I bet somebody else will supply that info.

Stop Plex, make a backup of Preferences.xml, and start by deleting MachineIdentifier and ProcessedMachineIdentifier.

Edit: possibly PlexOnlineToken also.

Threads that discuss these:

Two PMS servers on the same network - #12 by donglobal_gmail.com

400 Bad Request - #2 by OttoKerner

14

Let me put it this way…
Just because I change cars, am I going to reinvent the wheel?
How much? ALL OF IT; EVERY LAST APP!
Not that it necessary remained unchanged, but I’m a programmer from way back…
One never (or hardly ever) codes from scratch.
You take what you’ve got; modify and improve.

I take it since the issue was raised, the Plex account doesn’t just rely on the “friendly name”, despite what was indicated previously.
And, based on the usage exercised that I performed, we know that it CERTAINLY DOESN’T respond that way (just to friendly names)
So, yea, I’ve looked at the preferences.xml among all of the systems.
In the case of the Tower system (that got trashed), I don’t see any excuse for it;
ALL OF ITS MACHINE IDENTIFIERS ARE DIFFERENT from the other systems AND
certainly different from the system that did a mis-matched “setup process”, leaving it corrupted.
That would be for the Headless system which the Tower certainly is not, despite the original file transfer - ALL OF ITS APPS ARE DIFFERENT THAN THE SOURCE (its version of PMS is even from a different repository.)

So, not even close when it comes to this case AND it still needs to be ‘surgically’ rectified seeing how it is displaying the Library structure (upon “More”) from the other system, as well as its own.
You may have to tell me what I need to access ‘under the hood’ in order to rectify it.
(It was lucky I got the installation back at all through the “claim unsecured server” process.)

Now, as to the other systems in question - Headless and Rootless, which I conveyed to you that I actually witnessed the name of an authorized device ‘flip-flopping’ between the two.
THEY BOTH HAVE THE SAME MACHINE ID’s in Preferences.xml

I have proceeded to see how to retrieve a Machine ID and found a couple of interesting articles.
One was a response by you, Chuck, stating, “The only identification of the Server exists in Preferences.xml.” And the other was an article on retrieving base information from a Plex server (PMS installation) which I followed to find that the Machine ID extracted in such a manner only provided a number that matched the existing “ProcessedMachineID” in Preferences.xml.
I was hoping to ‘surgically’ replace the Machine ID in the Preferences.xml of the second system, but (lacking a good number to use) that hasn’t happened yet.

Anything I can do to ‘generate’ one?

15

Did you read my message and try what I suggested?

16

This system is riddled with bugs. Nearly worthless.

17

I think you’re on to something here. I was looking to replace the (duplicated) machine identifier on the second (cloned) machine, but ran into an issue or two (as conveyed to Chuck).
From what I have now read, I should have ‘nuked’ the identifier BEFORE I cloned, but a little late for that now. I’ll try the ‘retroactive’ method…
Kinda like “uncloning”.
(And, I remember who the original is; I was there for the procedure.)

18

Just got it and responded; was in the middle of writing to Chuck.
I’ll give it a try and let you know.

19

Hey Volts,

The ‘unclone’ procedure was a success!
Patient has a new identity (all three machine ID’s),
a new authorized device was created and the “fill-in-the-blank” PlexOnlineToken got handled too.
Just had to “claim server” to kick-start the process.

Thanks so much for the help.
Cary

20

[PLEX FAILURE to Connect / Stay connected to the Server WHERE IT RESIDES ]

Chuck,

This is STILL very much an issue - we’re back to Plex account dysfunction!

Now that every one of the servers (four of them) each with their own installation of PMS,
ALL HAVE UNIQUE “FRIENDLY NAMES”
ALL HAVE UNIQUE Machine Identifiers in Preferences.xml

They STILL are not connecting / staying connected to the Server installation where they reside.

If you check the accounting system it will show authorized devices for EACH of the four servers.
(Headless, Rootless, Tower, and Nameless, all by name)
AS WELL AS ENTRIES IDENTIFIED TO BE “Chrome” - adding another layer of ‘complexity’ and further emphasizing the Plex account dysfunction.

  1. I had deleted ALL references to “Chrome”, save for the one that shows “4.39.1” because I could not readily identify it or correlate it to the server machine that it is (was) associated with…

The others “3.95.2”, “4.30.2”, and “4.34.4” refer to the version of PlexWeb (of the PMS installations) that produced them and correlate to the machines Headless and Rootless (both with 3.95.2, that’s why there are two of them), Tower, and Nameless.
You will notice that despite having ‘nuked’ the “Chrome” authorized devices, they have been reproduced, IN LIEU OF USING THE EXISTING AUTHORIZED DEVICES BY NAME THAT WERE CREATED BY EACH OF THESE SYSTEMS…
And, that was AFTER each of these system was verified to be absolutely unique in their identifiers.

So, the first question which arises is, Why are the authorized device records produced by these systems NOT BEING UTILIZED subsequently? Which would serve to keep the proper PMS installations associated with the systems upon which they reside.

  1. I could tell that the named (by server name) authorized devices were not being utilized because when I would ‘nuke’ one of the “Chrome” authorized devices, the machine running PMS with which it was associated would tell me “Credentials expired please logon again.”

At which time, it would STILL NOT UTILIZE THE AUTHORIZED DEVICE RECORD IT HAD CREATED (previously), BUT WOULD PRODUCE A NEW “Chrome” RECORD.

  1. Each time one of the systems creates a new record instead of utilizing the existing authorized device record associated with it (by name that it had created), I have to RUN THROUGH A SETUP PROCEDURE (like what happened to Tower previously and corrupted it) AND RE-ESTABLISH ALL INCORPORATED LIBRARIES as to order and the way they are presented, i.e. GO TO THE LIBRARY TAB, instead of “Recommended” because it no longer “remembers”; the Plex account having produced a NEW authorized device record INSTEAD OF PROPERLY ASSOCIATING WITH EXISTING RECORDS.

This has now been done for multiple systems because of the consistent failure to properly associate with existing records.

  1. All of this further inspection of functioning was precipitated by the fact that one of the systems, “Headless” that had PMS running and still active, now appeared as “Nameless”, AND as I always had to do before when Plex “lost it”, restart the PMS container on the system to get it to reflect THE SYSTEM IN WHICH IT IS INSTALLED.

What gives with this continuing dysfunction?

Granted, being able to connect to another server might be a nice feature, BUT

  1. PMS installations SHOULD NOT BE “LOSING IT” by changing server references on its own whenever it feels like it.

  2. SHOULD UTILIZE EXISTING AUTHORIZED DEVICE RECORDS that the given device has already produced (unless someone specifically wants to create a new record and run through a new setup procedure by ‘nuking’ the existing associated record).

  3. A user SHOULD NOT BE FORCED to have to reorganize all of their libraries in a particular installation BECAUSE PLEX ACCOUNTING DECIDES TO PRODUCE A NEW RECORD (when a perfectly good record already exists).

Wouldn’t you agree?