QNAP - Every Update of PMS serve is unreachable.... for days

Plex Media Server NAS & Devices
1

Server Version#: PlexMediaServer-1.25.0.5282-2edd3c44d-x86_64.qpkg
Player Version#:

For the least several PMS updates, my server is unreachable. As time allows, I will stop and restart Plex, and after a few days of this, everything is working as expected across all clients (Plex or PlexAmp, Android, IOS, Windows, web, FireTV, etc).

I don’t want to go pouring over logs every time this happens (and of late, that’s every update). Any suggestions other than do the update and wait for it to magically fix itself?
Any chance my content stores are beyond what Plex can index/re-index efficiently when updating the server (I have a crazy large music collection?

2

Adding: Built-in web client cannot locate server either on either NIC.

3

The good news is there are people here who will pour over those logs for you. The next time it happens I would immediattly grab the logs and supply them here in a zip file.

I can’t imagine so. I also have a very large collection of media (working towards ~25TB out of about ~70TB or space). This has never caused any big issues. It sometimes slows the server down when I refresh all the metadata or optimize my database. Otherwise it peachy. I personally run my server from a Qnap TS-453D.

4

My thinking is that if workaround like changing the path (see: PMS on qnap loses library path after playing one or two source files) or manually forcing a re-index of the DB or in my case “waiting a few days” is what it takes, then by-golly (would never say that IRL), that’s what it takes.

But… but it didn’t used to be so. And it doesn’t need to be so either. Reading thru the forums, this does not appear to be isolated with just QNAP either.

5

Well it is definitely something not working right. I regularly update my server and have never had it go offline for days after an update, and I’m not running some high dollar super server. Its a home NAS with a fairly large data pool 96TB in total before RAID, and I have never had an issue.

6

Simple QNAP NAS here (TS-451+ with Expansion Cab, Celeron, 16GB RAM).

Logs.zip (5.7 MB)

7

Try disabling Plex by stopping the process.
Reboot your NAS.
Once restarted and completely loaded, start Plex back up.

8

If I may interject?

16 GB on a QNAP which is built for 8GB (2x 4GB) is asking for a :boom:

I’ve seen some very grossly unstable systems which were immediately stabilized when the correct amount of memory was installed.

QNAP units are extremely susceptible to failure when you exceed the spec.

You end up with the OS trying to use more memory than it can physically address (not enough circuit traces on the main board for it.

2 Likes
9

RAM has been installed for at least two years and no issues. Sure seems to help with containers.

So the reboot of the NAS appears to have resolved the Plex issue. @Blkbyrd - Thank you!
Hate it when I forget the most basic like “did you reboot?”

Question remains: why PMS seem to need time and/or a reboot to be discoverable again?

10

The issue is that PMS didn’t close properly and some of its child processes remain running because they don’t get killed off. To make sure that doesn’t happen in the future when you do an upgrade, make sure to shut PMS down, do the upgrade, wait a few minutes and then start it back up.

11

I will look at the scripts again to see if I can make it more bullet-proof but I don’t have any control over QTS closing down and recycling ports when PMS commands all the support processes to shut down,

There is a bit of a race condition between PMS exiting - QTS thinking it’s stopped - and the rest of the ports all being closed so you can restart

I used to have a mandatory wait period in there.

I wonder if it’s time to start using it again

12

Also just because it gave the impression it is working does not mean it is A. actually doing anything or B. not going to cause a huge issue later. Chuck wouldn’t tell you that to rain on your parade. He is trying to save you from having any sort of massive issue down the road.

13

To share WHY I say it.

  1. HW transcoding uses system RAM directly.

  2. If the system thinks it has more memory than it actually does.

  3. A hardware transcode comes along, Reading from the input buffer and writing to the output buffer

  4. The problem is – The “output buffer” happens to be in the kernel memory because of address bit wrap around.

I’ve seen it happen.

I’m not trying to rain on any parades.

Just sharing what i’ve seen

If rebooted often and memory demands low, then it may never occur
When the demand for memory goes up, so do the risks

14

THIS !!!

15

@ChuckPa I would have assumed that if moving in and out of virtual memory space, Linux would handle since the allocations of physical precede the use. I will monitor more closely.

16

Yes, but there’s a big catch!

Linux reads the SPD information off the DIMMs.

It configures itself with that information.

It trusts the hardware is correct because the ONE THING it can’t detect is address wrapping or, for that matter, if two pins of a DIMM are shorted together.

Linux doesn’t perform a full “Memtest86” sweep of memory when starting up.

It goes by what the Firmware (UEFI/BIOS) tells it – which came from the SPD scan.

For as exaggerated as it sounds, you can make a 4GB DIMM which reports that it’s 64GB and the software would believe it

The reverse is true, which is why I caution.

I can put 128GB in a machine (because the power pins, command, and main address pins all line up per the spec.

What Linux doesn’t know – Are there circuit traces on the main board ?

Look at the notation in binary using a simple 1->8
0 = 0000 (address zero is always valid)
1 = 0001
2 = 0010
4 = 0100
5 = 0101
6 = 0110
7 = 0111
8 = 1000
…
…
16 = 10000

The NAS has address line for 0 → 7FFFFFFFFF ( 8GB )
but does it have the next bit? 8000

That’s the problem.

Look at the bits

1 GB = 2^30 = 1,073,741,824
2 GB = 2^31 = 2,147,483,648
4 GB = 2^32 = 4,294,967,296

Did QNAP put more than 32 address lines to the DIMM?

If they did, 36 (groups of 4) would make FAR more sense.

What you get is “bank switched 2x 4 GB” for a total of 8GB

17

@ChuckPa As always, a master class!

I have put the questions to QNAP and look forward to their response. While this is good information, do you believe it is tied to root cause for why each Plex update causes an undiscoverable Plex Server?

18

I may be speaking a little for Chuck here, but the reason your server becomes unreachable is because during the update when the server is shut down by Qnap it doesn’t take enough time to actually kill all the child processes of PMS before indicating that it is shut down. Those processes are then left kind of like zombies, and when it starts PMS back up thinking everything will be fine it can’t actually load up correct because those child processes from the previous instance are still hanging around getting in the way. To eliminate this rebooting your device will make sure that those processes are properly killed before starting PMS back up. This should only really be a problem when you need to shut PMS down for an update or something.

19

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.