Error on start - plexmediaserver (1.29.1.6260-420892357) - drmGetDevices2

Thank you, Now I understand.

That How-To is pretty grossly outdated because of internal changes to both PMS and the Nvidia drivers since that article was written.

To run down the list

  1. The biggest change is - PMS uses musl instead of ld.so.

  2. plex.sh takes this into account. It also takes standard QNAP /opt/NVIDIA_GPU_DRV into account via gpuhal_app .

  3. To keep the layers clean,
    – the docker container definition addresses the app needs
    plex.sh addresses bringing the appropriate runtime libraries, which includes the GPU libraries, to PMS.

  4. PMS will always favor the Nvidia GPU over the CPU when it finds it.

On a system which has a QSV capable CPU, it is a requirement to add the preference HardwareDevicePath="/dev/dri/renderD129" (Default is renderD128)

For the longest time, I’ve wanted to lower PMS’s privilege level on QNAP.
It’s not possible because QNAP does not have udev nor does it have a real sh/‘bash’ shell (it has busybox). There would be secondary issues with everyone being frustrated about granting media permissions just like they were with Synology.

I’d very much like to solve this once and for all.

From the top — :slight_smile:
Which CPU and GPU do you have in your machine?

1 Like


I made sure to map that specific GPU on the compatibility list, so if you come back and tell me it’s not I’m gonna be upset!! lol

You have a GP107. :+1:

If you SSH into the shell now, what do you see in /dev/dri?

image

card0
card1
renderD128
renderD129

Thanks, as I thought.

  1. Stop the container.
  2. Using the QNAP text editor app, navigate to where Preferences.xml is.
  3. Edit Preferences.xml
  4. If you’ve not previously added it; on the last line, before the closing /> marker,
    – add HardwareDevicePath="/dev/dri/renderD129'

You should see: SomePref="value" HarwareDevicePath="/dev/dri/renderD129" />

Save the file.

Start the container

PS: It might help to use a simplified container definition given how exotic yours is
(create a test container by copy/trim)

OK, that’s done. I’ll trim down my container config and try running with your example first. Report back soon!

Rather than disturb yours,

Create a new container (different name) and use the simplified definition – but still pointing to where your /config resolves.

That way, you have side-by-side comparison using the existing PMS server instance and metadata.

Last thing - Should I run your plex.sh from the other thead, or is that not needed any longer?

sorry for delay. No need to run plex.sh

Let the container do its thing normally.

Alright - New container is up on 1.29.1 but GPU is not being utilized with those settings. Transcode is being done through the CPU.

docker run -d --name plex2 --network=host -e TZ=“EST” -e LANG=“en_US.UTF-8” -e PLEX_UID=0 -e PLEX_GID=0 -e PUID=0 -e PGID=0 -h DockerPlex -v “/share/CACHEDEVX_DATA/.qpkg/PlexMediaServer/Library/Plex Media Server/”:/config/ -v “/dev/shm:/transcode” -v “/myshare/:/certificates” -v “/myshare/:/media” -v “/myshare/”:“/music” --device=/dev/dri:/dev/dri plexinc/pms-docker:plexpass

I lost permissions to my Preferences.xml as well for some reason. Trying to see how I can view it on the QNAP side. They keep obfuscating things from the CLI and I don’t like it!

Grab DEBUG logs please?

Let me see what it doesn’t like

Plex Media Server Logs_2022-10-21_19-05-58.zip (609.1 KB)

Here you are. I started debug before playing a file. I’m remote right now but playing direct (not through plex.tv). Hopefully you can find something in there. If you need something else or me to do something differently just let me know.

Found lots of goodies in there :smiling_imp:

This one’s for you

Oct 21, 2022 19:04:11.250 [0x7f394422d6f0] INFO - [CERT/OCSP] Successfully retrieved response from cache.
Oct 21, 2022 19:04:11.250 [0x7f394422d6f0] ERROR - [CERT] Found a user-provided certificate, but couldn’t install it.

We’ll work on this:

2022 19:04:11.400 [0x7f393d3a3b38] WARN - [GPU] Failed to load PCIID map: Failed to locate a readable PCIID database

You’re burning subtitles – CPU will be utilized and the hardware turned off

Independent of all that –

  1. You have a CoffeeLake CPU which has native QSV support through /dev/dri/renderD128

  2. Go back and look at the the screenshot of your GPU.

I think this is the root cause .

Supplementally, This TS-877 is running QTS 5.0.1.2173

Care to consider updating to a known-good version?

1 Like

ah d#@$ - I need to restart my QNAP. I’ve had that issue before with zeroed out resources and a restart fixes it. I think it’s due to the nature of how I needed to run the container in the past.

I checked my stream and subtitles are not selected, so it’s strange they are burning even though not selected. Where is that option set - I’m having some trouble finding it at the moment?

As for my certificate - That’s also strange because my direct connect shows a green banner with valid certificate (using a traefik proxy, exporting the cert through cron job/script for updating whenever it expires).

My TVS is running this version driver - the lack of version number in the background App Center is likely due to the HW resources being zeroed out:

I probably won’t get to restarting until tonight as I have about 20-30 other containers running on this guy. I’ll resolve that stuff and let you know my luck after I resolve the Hardware issue at a minumum!

Just saw your comment on the driver version itself too. I’ll get the Kernel updated at the same time. Looks like GPU version is good atm and saw your comment above on 5.1 being buggy.

We have one option given this is an i3-8100 –

Install the native package (if your container’s storage location isn’t in a .qpkg directory).

This way, we can confirm native PMS can use both QSV and Nvidia natively.
Once native support is confirmed then step into the container.

Would you happen to have the 5.0.1.2173 Kernel QKPG? It looks like QNAP took them off of their site completely now for some reason:

Unfortunately that is not an option as this model NAS can only pass the GPU through to Container Station. I was previously using the native app until that limitation hit :-/.

Also - Config is in .qkpg directly given I was previously using the native app.

I’m headed out for now, but will get my NAS restarted tonight after home distractions are at a minimum and fill in any details afterwards.

If you have PMS already installed natively — :smiling_imp:

  1. Stop / disable the container
  2. Give this a proper shot (manual install on top of your existing)
  1. REMOVE HardwareDevicePath from Preferences again.
  2. start the native app.
  3. Behavior should, without errors, be - tone mapping operational using CPU/QSV

From there, we can dig deeper into the container/Nvidia if you wish.

I’ve been following the above… Managed to get it to HW transcode however not to the GPU.
What else should I be looking at?

new docker-compose
plextemp:
    image: plexinc/pms-docker:plexpass
    container_name: plextemp
    restart: always
    network_mode: host
    devices:
      - /dev/dri:/dev/dri
    environment:
      VERSION: docker
      PLEX_UID:   "0"
      PLEX_GID:   "0"
      PGID: "0"
      PUID: "0"
    volumes:
      - "/opt/NVIDIA_GPU_DRV/usr:/usr/local/nvidia:rw"
      - "/share/Container/docker/media/plextemp/:/config:rw"
      - "/share/PlexTranscode:/PlexTranscode:rw"
      - "/share:/share:ro"

My Concern is that this will not work given the response from QNAP support I got earlier this year:

This unit can only use the GPU for Container Station (even though QTS is an available option in the QNAP OS).

If you feel confident the native app can pass through with the new changes you’ve made, I’m all for it though - will wait for your confirmation! :slight_smile: