Pms-docker unavailable semi-sporadically

Plex Media Server Desktops & Laptops
1

Server Version#: 1.18.2.2058
Player Version#: Android 7.24.3.13840

Plex Media Server running in CentOS 8 Docker, official plexinc/pms-docker image
Media streamed from Android Plex App to Google Chromecast Ultra over insecure connection

Docker-compose config 
version: "3"
volumes:
  video:
    driver: local
    driver_opts:
      type: nfs
      o: addr=storage,vers=4.1,rw,nolock,async
      device: ":/mnt/mainpool/export/Shared/Video"
  config_plex:
    driver: local
    driver_opts:
      type: nfs
      o: addr=storage,vers=4.1,rw,async
      device: ":/mnt/mainpool/vmdata/configuration/plex"

networks:
  internal:
    internal: "true"

services:
  plex:
    image: plexinc/pms-docker:latest
    restart: unless-stopped
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - config_plex:/config:cached
      - video:/media
      - /tmp:/transcode/Transcode/Sessions # tmpfs
      - "/tmp:/config/Library/Application Support/Plex Media Server/Codecs" # tmpfs
    environment:
      - CHANGE_CONFIG_DIR_OWNERSHIP=false
    ports:
      - 32400:32400/tcp        # Media Server
      - 3005:3005/tcp        # Plex Companion
      - 32410:32410/udp        # GDM discovery: needed for plex cross discovery
      - 32412-32414:32412-32414/udp        # GDM discovery
    networks:
      - default
      - internal

Issue:

There is this weird (semi-?) sporadic issue after playback where the plex media server sometimes goes unavailable for all devides, and after waiting for a few minutes everything seems back to normal.

It is not 100% of the time, and I feel like it might be occurring less frequently when I let next episode load automatically. This issue also does not seem to occur for some time right after the container is started up initially/or restarted.

Problem also happened a ton more when I was initially scanning libraries and downloading metadata. Server was basically unreachable for most of their duration.

Symptoms:

  • Videos play in full, but when next episode is selected “content unavailable” is seen frequently
  • Server recovers in less than 5 minutes, but during this duration all media seems unavailable
  • No crash indication in docker logs

Background:

Recently I moved my media server to new platform as part of hardware upgrades (CentOS 7 -> 8, local mounted volumes -> nfs mounted volumes).
I had similar problem early on in the old system, but it was caused by incorrect ports being open. That should not be a problem here at least by configuration now.

I have been thinking this is an issue somehow related to the nfs volumes, and I’ve moved parts of config data back and forth, and adjusted the nfs server settings to see if something in particular would sort the issue, but no luck.

Parts of the config I have not yet moved to local storage are ‘Media’ and ‘Metadata’, as I would like to keep those on persistent storage independent of the container host…

Any suggestions what might be causing this behavior?

2

I’ve kept tabs on where and how often this happens, and noticed that its not limited to playback on any particular device or whether the media next media is autoplayed or not.

Also its not semi-sporadic anymore, if I’m lucky I can get two 24min episodes in before the content goes unavailable and I have to wait before continuing. I’ve also noticed that after content is back available, the previously watched episode is only 33% or 66% watched and I have to manually change it to 100% watched.

3

Seems like NFS was the cause after all. I moved the entire Application library to local storage and preliminary testing indicates no content issues…

Sooo… anyone got any idea how to keep the application libraries on NFS share without the observed side-effects?

4

In general we do not recommend putting the Application Support directory (assuming that’s what you are talking about) on network storage because it can be unreliable. NFS is likely more functional than SMB as the latter will corrupt your database. You must have file locking allowed on your NFS mount.

Given the symptoms reported above, your issue could be reliability with the NFS server/mount itself. You may want to investigate this first.

5

Yes, I meant Application Support directory. File locking is by default enabled on NFS clients according to man-pages.

I’d like to believe the NFS is performing fairly well, but then again there is plenty of evidence against that claim…

I’d like to think software is configured correctly but hardware is not optimal for the type of data in the plex directories. However I could be wrong, so keeping tabs on nfsstat on both server and client for failures now as well as doing some random access performance testing.

For reference, there is currently a Cat 5e (1Gb LAN) and unmanaged network switch between NFS client and server, which is pending update to 10Gb SFP+ direct connection. Underlying storage is 3+3 drive RaidZ stripe (zfs) that looks to be capable of ~400 iops on average (maybe that is why?).

Are there some particular files/directories, which are accessed more often that would benefit mostly from being in fast access storage, aside from the transcode directory?

6

The most accessed file in the Application Support dir is: Application Support/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.db and its associated files. This is the primary database for the whole server.

7

Thanks for information, I will do some testing to see if I can move some parts back to the NFS storage off the docker host.
If I find a working setup, I will post it here for anyone else interested in similar configuration.

8

I have had exactly the same issue, with a very similar setup (Docker host running on an Ubuntu VM, plexinc/pms-docker image, NFS shared Library folder (and obviously therefore Application Support folder) via NFSv4 from a QNAP NAS.

Moving it all to local storage fixed the issue. But the motivation for having it served from NFS is still there - chapter thumbnails mean the Application Support folder branch gets huge, too large for local storage so I’ve had to switch thumbnails off (not ideal). Also, I’d prefer this was RAIDed which I don’t get on my local storage. I’m also very keen on having everything scripted so I can spin up a replacement server in no time, with all config stored.

I’d still like to try to get this working reliably, so I’ll continue playing and if I find anything useful I’ll share it here.

9

That right there is my motivation as well. I have redundant storage, so its not in a big hurry, but at the same time, size is a consideration.

Also, if I do manage to get it to a functional level I will move the service off a single-node docker host to a clustered service. (My primary reason to get away from local storage)

10

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

12

Returning to post results, in case someone stumbles on this thread later on:

As pointed out by gbooker02 [Post 6], keeping following files on local storage is enough to solve most performance related issues:

com.plexapp.plugins.library.db
com.plexapp.plugins.library.db-shm
com.plexapp.plugins.library.db-wal

Basically what I’ve done is:

  1. copy com.plexapp.plugins.library.db to fast static storage
  2. generate empty files for docker referencing (if you do not have existing ones to use) 
touch com.plexapp.plugins.library.db-{shm,wal}
  1. match other Application Support file ownerships, otherwise you will get read only errors
chown <plexuid>:<plexguid> com.plexapp.plugins.library.db*
  1. add following references to docker-compose config:
volumes:
  - "/path/to/com.plexapp.plugins.library.db:/config/Library/Application Support/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.db"
  - "/path/to/com.plexapp.plugins.library.db-shm:/config/Library/Application Support/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.db-shm"
  - "/path/to/com.plexapp.plugins.library.db-wal:/config/Library/Application Support/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.db-wal"

I decided it is best to keep only these files in fast access storage, as opposed to the entire database directory, as plex creates backups of database files every now and then.
If the entire database folder is in fast access storage, then backups will also stay there instead of being on my better backed storage medium.

1 Like
13

This issues you guys were having was it web player or via an app?

Ive got my server setup in docker connecting to a movies nfs share. Server plays flawless on chrome browser connecting to server however when adding the server to apple tv it shows:

{Server Name}
Unavailable

Any thoughts?

I tried these steps here

  1. Uninstall the Plex app from the Apple TV
  2. Power off the Apple TV
  3. Unplug it, wait 10 seconds, plug it back in
  4. Reinstall the Plex app

had it briefly show “remote” (like it was going to work) before failing to connect in the end and when restoring it shows again Unavailable.

14

That sounds like a different problem, in my case media was always available at first, but no more after playback for some time. Make sure you have advertise addresses correctly configured in case you are running bridge mode (see pms readme)

If you read my first post, I am describing Android and Chromecast client setup. I do not know if Apple TV has some special requirements for it to work, so you’re better off looking in other topics if referencing official docs and verifying your config does not work.

15

This is such a simple workaround to an ugly Plex problem that has plagued me on and off for months. Three bind mounts fixed the performance and stability issues!