Hardware Transcoding issues - ApolloLake & GeminiLake CPUs

@cypekis11

In your container definition, you’re specifying PGID = 100.

/dev/dri is always owned by root so you’ll never get access with PUID directly.

Is UID 1026 a member of the group which owns /dev/dri/card0 & renderD128 ?

The PGID you specify won’t work on Synology (user group has no access there)

FYI, you no longer need (for some time now) to use Docker for HW transcoding and tone mapping. It all works natively.

As for using build 6999, I also recommend using it for now. ApolloLake fix will be in 1.32.5.

Hey,
I’m on vacation but keep seeing ApolloLake mentioned, what about Geminilake? I don’t believe this issue is fixed for those either without manually putting the driver in the Cache folder under Plex settings.

@CT9AJ

If I can get reliable logs for GeminiLake CPUs , it’ll get fixed.

I have a 1520+ with a geminilake but using docker so couldn’t test the spk files. Currently sticking with version 6999 now

@ampersandTV

If you’re strategic, you can have both Docker PMS and Native PMS be interchangeable.

I have a How-To for that.

If you run the current PMS docker image, you can capture the same DEBUG info as the native app because both are using the same binary executables.

Can you share this how to?

i believe he is referring to his FAQ

That’s the one. The tricks are:

  1. PMS is installed (it creates the shared folder and grants the HW permissions)
  2. The docker container runs with PUID & PGID of DSM 7 user “PlexMediaServer”
  3. /config/Library/Application Support is mapped to /volumeX/PlexMediaServer/AppData

The How-To details how to do this.

Why Dockerize what can and should run native, unless you really Cloud Provider?

Docker is more complexity in Kernel tables, etc.

1 Like

@Horia_Miclea

You’re right. Docker is more complex. There are those who feel docker is the answer to everything.

I believe “the right tool for the job” and “Use docker when no native package is available” (how it was intended).

2 Likes

I totally agree. Especially those like me that simply use the box to run plex - no idea why they insist on going through docker for zero reason.

Several people tell me around this problem, that hi hasn’t with the last docker version…in the same 920+ this could be a coincidence? Or docker is more stable?

@ChuckPa
Here are some logs from me testing on Version 1.32.4.7195 with my DS920+

Test #1: Playing LG Colors of Journey HDR 4K Demo (no driver in Cache folder and no i965 mentioned in Preferences.xml (CPU shot to the moon)
Plex Media Server Logs_2023-06-16_10-01-18.zip (4.2 MB)

Test #2: Playing Jellyfish 80 Mbps Hd (no driver in Cache folder and no i965 mentioned in Preferences.xml) (CPU was steady)
Plex Media Server Logs_2023-06-16_10-03-48.zip (4.2 MB)

Anyone who has been a sysadmin on any type of server will tell you about dependencies.

Docker removes that word from system administration.

New version of slapjack? Spin it up in Docker, it won’t break the other tools on the server…

New version of Plex? Spin it up in Docker.

When you go the native route you’re always running into new libraries, that other tools don’t work with, then you have to update those tools, then you have to update to libc++ 17.0 because something needs it, then you just broke 3 other tools that use libc++ 11.0……

Docker removes all those layers of sysadmining that are despised, with a little bit of up front setup.

@ChuckPa
Now I re-did those 2 tests above but this time I placed the i965 driver in the va-dri-linux-x86_64 folder.

LG Colors of Journey HDR 4K Demo (CPU did not shoot to the moon)
Plex Media Server Logs_2023-06-16_10-09-14.zip (3.5 MB)

Jellyfish 80 Mbps Hd (CPU was steady for this again)
Plex Media Server Logs_2023-06-16_10-11-06.zip (3.5 MB)

Hope this helps.

I have never once run in to any such issues, running it native on my Synology.

Yes, I understand the game changer about dependencies, specially for developers with several library versions etc…but, I think the best performance always be on native applications, because docker is in some way an extra layer…what I can’t understand about this issue, if we’re talking about the same binaries, why works on docker an don’t on native in the same machine??

1 Like

From what I understand in the thread, ALL the new versions of PMS break hardware encoding on the DS920+ (and other Synology NAS devices).

Native or Docker container, if it’s past version .6999 it’s broken.

I personally just happen to run PMS in a Docker container on my 920+ because I also have pi-hole, sonarr, radarr, nzbget, etc. running in containers as well.

I didn’t want the headache of dependencies.

If I may add ?

  1. Plex brings all its dependencies with it in every SPK file with exception of codecs and drivers.

  2. Codecs and Drivers are downloaded and stored in the PlexMediaServer shared folder the first time PMS starts up. As versions update, these are automatically updated in sync with the SPK files.

  3. There are no external dependencies.

1 Like

Hey Folks,

Quick update on Apollo Lake CPUs.

I’ve been working with @ChuckPa. I loaded an alpha (pre-QA) version of PMS 1.32.5 on my DS918+, which has the Celeron J3455 CPU.

Here’s some initial results:

Jellyfish 80 Mbps H.264 HD & 120 Mbps HEVC UHD: Hardware transcoding engaged. Playback was smooth, with no buffering.

LG New York UHD HDR: Hardware transcoding & tonemapping engaged. Colors looked good. Playback was smooth with no buffering.

LG Colors of Journey UHD HDR: Hardware transcoding & tonemapping engaged. Colors looked good. Playback did buffer a few times. However, this video is 60 FPS, so it is pushing the limits of the J3455.

Clients were Android mobile on a Pixel 6a, configured to transcode to 1080p, 8 Mbps, and Plex for Windows, forcing a transcode to 1080p, 10 Mbps.

I loaded the alpha on my system a couple of hours ago and ran the tests. Chuck asked that I drop an update to the thread. Wanted to let you know things are progressing.


Screenshot (1761)

4 Likes