Just back from holiday.
As UglyMagoo inferred, we need to be really careful with the older GPUs. Compared to anything 4th generation (-4xxx) and newer, they are not very reliable.
Thanks @uglymagoo for stepping in.
Just back from holiday.
As UglyMagoo inferred, we need to be really careful with the older GPUs. Compared to anything 4th generation (-4xxx) and newer, they are not very reliable.
Thanks @uglymagoo for stepping in.
@uglymagoo said:
@BeyondEvil said:
“Good” to see that someone else has the same/similar problem.The other user also has a Sandy Bridge CPU. Unfortunately, my oldest CPU at hand is an Ivy Bridge with a completely different GPU implementation, so I am unable to recreate this problem myself
So the common denominator (so far) is Sandy Bridge (and linux ). Maybe this will be the argument I need to convince my SO that I really need to build a new setup now, lol.
@ChuckPA said:
@BeyondEvilJust back from holiday.
As UglyMagoo inferred, we need to be really careful with the older GPUs. Compared to anything 4th generation (-4xxx) and newer, they are not very reliable.Thanks @uglymagoo for stepping in.
I hope you had a pleasant one. ![]()
So, trying to fix this issue might not be worth it? Don’t get me wrong, I’m happy to do whatever is in my power to help but it seems we’re nearing us layers in the OSI that I have zero experience with.
“VA-API is the second dominant video API to VDPAU for suitable video acceleration under Linux. VA-API is the choice of Intel’s open-source Linux graphics driver. Particularly if using Sandy Bridge or Ivy Bridge graphics hardware with their open-source driver, the Video Acceleration API is wonderful.”
meh…
https://www.phoronix.com/scan.php?page=news_item&px=MTEyNDk
Guess I’m back to experimenting with kernel and VAAPI then… Feels like I have nothing to loose at this point. If I fail, I’ll just build a new box. I’ve been wanting to try out unRaid anyways…
I wonder if this is something that I can adapt to CentOS:
@BeyondEvil said:
“VA-API is the second dominant video API to VDPAU for suitable video acceleration under Linux. VA-API is the choice of Intel’s open-source Linux graphics driver. Particularly if using Sandy Bridge or Ivy Bridge graphics hardware with their open-source driver, the Video Acceleration API is wonderful.”
The thing is, while Plex bundles a very recent “intel-vaapi-driver”, the real work has to be done by the i915 Linux module. And the i915 module in your kernel is very old
And the problem of the other user magically disappeared. Maybe, it was because of a kernel update ![]()
“The current video driver backend provides a bridge to the GEN GPUs through the packaging of buffers and commands to be sent to the i915 driver for exercising both hardware and shader functionality for video decode, encode, and processing.”
Good luck and keep us posted!
I wonder if this is something that I can adapt to CentOS: How To Enable Intel SNA Acceleration In Ubuntu ~ Web Upd8: Ubuntu / Linux blog
Not related to Plex at all. “SNA is a 2D acceleration architecture for the open source Intel Linux graphics driver that provides improved X.Org driver performance”.
@uglymagoo said:
Good luck and keep us posted!
Thanks! I really appreciate all the help you guys have provided! ![]()
I’ll definitely keep this thread updated with my findings. ![]()
So I’ve done a little more research and experimentation.
In short:
Got a more recent version of the i965 driver and replaced the one bundled with Plex. Hit another issue.
Here is more info.
In reference to that I saw that @ChuckPA has seen that issue before, and like above, am I on some kind of path to fixing this - or is it just another rabbit-hole?
What are the permissions on /dev/dri and the files in that directory?
/dev/dri/renderD128 should be root:video and user plex should be a member of group video.
Both card0 and D128 are root:video and plex is a member of video.
I also forgot to ask kernel version. You must remember… On linux, the 4.x.x kernels, specifically starting with those in Fedora 26 are what’s supported. If you’ve got older, it is hit or miss when not using QSV
For reference. Fedora 26 is currently at
Linux lizum.hessen.lan 4.15.12-201.fc26.x86_64 #1 SMP Thu Mar 22 19:24:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
The kernel (updated a couple of weeks ago) is 3.10.0-693.21.1.el7.x86_64
But the question how much that really says, since the CentOS folks still patch and backport stuff…
On the other hand, maybe they don’t backport stuff that is relevant to us.
I’ll install the latest (4.16 is the current mainline/stable one) and see what happens.
Edit:
Updated the kernel. Same problem (libcuda).
PMS is aware of libcuda. If it’s there properly, it will use it. Getting it there properly is the part that’s on you. You need the proprietary drivers and X server config settings. What you’re seeing with that Kernel is it looking, not finding the QSV support it needs and falling back.
You said there was a kernel update. Now you need go find out if the Xserver config got dinged in the process.
I am sorry but on Linux non-QSV is out of scope for me because it’s not yet (forgive me) “officially supported”. If it works, great. If it doesn’t , <shrug>.
I can tell you, when libva 2.1.x is implemented, with exception of the local host library (libcuda, and the Xserver config), this fuss will be moot. It will be there automatically just as QSV is
@ChuckPA said:
PMS is aware of libcuda. If it’s there properly, it will use it. Getting it there properly is the part that’s on you. You need the proprietary drivers and X server config settings. What you’re seeing with that Kernel is it looking, not finding the QSV support it needs and falling back.You said there was a kernel update. Now you need go find out if the Xserver config got dinged in the process.
I am sorry but on Linux non-QSV is out of scope for me because it’s not yet (forgive me) “officially supported”. If it works, great. If it doesn’t ,
<shrug>.I can tell you, when libva 2.1.x is implemented, with exception of the local host library (libcuda, and the Xserver config), this fuss will be moot. It will be there automatically just as QSV is
Now I’m (still?) confused, in more than one way.
Re Sandy Bridge.
To cut it right to the core: There are old issues in the libva code which Intel, because of the age of the CPU, has flagged WONT FIX and there’s nothing we can do about it. In that same breath, should they break something, I don’t know how receptive they will be in fixing any breakage.
It may have been great on Windows for a long time. This is Linux… Different animal. We didn’t have viable QSV until Carpalis (a github user) found and fixed the bug in the core Intel routines.
Since that date (Aug-Sept 2017) Intel has poured forth huge effort to bring us from 1.8 to where we are now with 2.1. In all that, Intel added ALL the processors which didn’t exist previously (a rather long list). They also have been adding support for all the upcoming processors
throughout all of this, nVidia and AMD had their solutions. If they don’t work, I will ask you to take it there.
PMS does not install libcuda.so, you did.
I have an nVidia GPU in this computer and I do not get the errors you report but I didn’t have hardware transcoding installed.
That said… What was installed and what broke? If you remove the proprietary and only have QSV installed, then we can dig but I’m not convinced that’s the case because this is all about what happened after an OS Update.
First of all, I think I have to apologize, because I think I am the root of the confusion.
I’ve been at this for so long and I’ve been doing so much back and forth that it’s difficult to keep track. On top of that, I’ve been getting some help from the Emby forum thread posted earlier - which adds to everything.
Again, I’m really thankful for your patience and help, Chuck!
I’ll answer below and try to be as verbose and detailed as I can about what I’ve tried lately and the (lack of) results.
@ChuckPA said:
Re Sandy Bridge.To cut it right to the core: There are old issues in the libva code which Intel, because of the age of the CPU, has flagged WONT FIX and there’s nothing we can do about it. In that same breath, should they break something, I don’t know how receptive they will be in fixing any breakage.
Fair enough.
It may have been great on Windows for a long time. This is Linux… Different animal. We didn’t have viable QSV until Carpalis (a github user) found and fixed the bug in the core Intel routines.
Not sure how Windows came into play. The mac mini is still dual boot, I’ll see if I can boot into macos for comparisons sake. I used to have everything (PMS etc) setup there, so I should be able to get it working.
Since that date (Aug-Sept 2017) Intel has poured forth huge effort to bring us from 1.8 to where we are now with 2.1. In all that, Intel added ALL the processors which didn’t exist previously (a rather long list). They also have been adding support for all the upcoming processors
So adding old CPUs but not fixing any errors/bugs?
throughout all of this, nVidia and AMD had their solutions. If they don’t work, I will ask you to take it there.
Irrelevant in my case since the CPU is Intel and so is the GPU.
PMS does not install
libcuda.so, you did.
Well, I didn’t. I just stated what the error log said.
I have an nVidia GPU in this computer and I do not get the errors you report but I didn’t have hardware transcoding installed.
That said… What was installed and what broke? If you remove the proprietary and only have QSV installed, then we can dig but I’m not convinced that’s the case because this is all about what happened after an OS Update.
So two things happened at the same time.
with the new ones from negativo17
The latest libva stuff gives me the errors and falls back to SW transcoding.
Updating the kernel doesn’t seem to have changed anything.
Here’s something that I just realized that maybe can play a part in all this:
When I originally installed PMS I installed the 32-bit version (unknowingly): https://forums.plex.tv/discussion/309726/yum-update-fails-with-transaction-check-error#latest
That was fixed.
But PMS still resides in /usr/lib instead of /usr/lib64 is that correct?
@BeyondEvil said:
- I installed the latest libva and libva-intel-driver from the negativo17 repo and replaced:
- i965 driver in /usr/lib/plexmediaserver/dri/
- libva.so in /usr/lib/plexmediaserver/
- libva-drm.so in /usr/lib/plexmediaserver/dri
If you overwrote the Plex supplied i965 file, that’s entirely on you… OOOOPS.
Same with overwriting the Plex-supplied libva in /usr/lib/plexmediaserver.
ALL STOP.
NOT A PLEX PROBLEM because it’s NOT PLEX SOFTWARE
@ChuckPA said:
@BeyondEvil said:
- I installed the latest libva and libva-intel-driver from the negativo17 repo and replaced:
- i965 driver in /usr/lib/plexmediaserver/dri/
- libva.so in /usr/lib/plexmediaserver/
- libva-drm.so in /usr/lib/plexmediaserver/dri
If you overwrote the Plex supplied i965 file, that’s entirely on you… OOOOPS.
Same with overwriting the Plex-supplied libva in
/usr/lib/plexmediaserver.ALL STOP.
NOT A PLEX PROBLEM because it’s NOT PLEX SOFTWARE
Heh, no silly. Of course I backed them up first. ![]()
What about the lib vs lib64?
@BeyondEvil As @ChuckPA has told you, the official standpoint is, that Plex cannot fix intel bugs and the halted development of intel for Sandy Bridge.
Just an idea, if you still want to debug the issue further: please do not experiment with Plex and libva. It’s much more fruitful to experiment with ffmpeg and its h264_vaapi encoder directly and leave Plex out of the picture for now. Please re-encode the files, that produce errors in Plex, with h264_vaapi and also burn subtitles into the re-encode. Then take a look at the result. If it is also broken then there is definitively nothing Plex can do.
Thanks!
I tried it on the MacOS installation, and there it worked. So at least it’s not the hardware that is the issue.
Next, I’m going to try with ffmpeg. Is there a good resource you could point me to for learning?
@BeyondEvil said:
Next, I’m going to try with ffmpeg. Is there a good resource you could point me to for learning?
6 posts were split to a new topic: Cgroup changes impacting Docker HW access