Is this release supposed to fix this issue? Because…it doesn’t.
![]()
Is this release supposed to fix this issue? Because…it doesn’t.
![]()
It does fix it on all tested platforms with exception of GeminiLake … Some GLK machines / mobos don’t function as they should.
Definitely need to see your logs (including a PMS restart to track device detection) of a playback attempt.
I’m running an Intel Arc a40 Pro on Debian 12 with kernel 6.7. Is that one of the platforms that this fix applies to? If so, I can provide logs.
I would consider updating to 6.8, confirming any ARC driver updates for kernel 6.8, regen the initramfs and then retest.
I would very much like to see the server DEBUG logs ZIP file from PMS start to invoking a transcode.
I’m happy that after only six months we finally have that admission: the bug was not in the Linux kernel, as too many times has been said in this thread, but in the PMS.
Anyway, thanks for your work, I hope that you can also understand what is still not working in GeminiLake because my home server has exactly that CPU.
Looking forward to ear good news from your side soon.
Regards and good work.
I’m sorry? where did I say this?
Whats the best way of collecting logs and submitting it for a bug report since this latest beta version has a problem (which i described in a previous comment) when transcoding - it works for some clients (ie: chrome, iPhone), but fails on others (eg: safari, and my LG OLED screen). the previous version worked fine.
I will open a PM for you . You can attach your logs there.
The best logs to provide are:
Just because you asked, I don’t have any negative intention:
On contrary to what you said on this post I think that you should use a lot more the beta kernel as testing platform for new PMS releases in order to verify if your software will continue to work on future kernel releases or you need to adapt the code before that kernel beta version comes out as stable…
As I said before, now I’m happy that the issue has been resolved on most of the problematic HW/SW combinations, I hope you can also solve the remaining issue with GeminiLake CPUs.
Regards
I think he was questioning where he said the issue is in PMS. But that’s just my guess.
Thank you VERY much for clarifying!
I had not presumed any ill intent from you whatsoever.
I SHOULD and will be more clear when I state things… Thank you.
Testing BETA software (at the OS / kernel level) is truly a moving target.
You can have multiple “beta” releases from the developers before you get “Release Candidate” grade.
I should , and will moving foreward, state what is being tested.
I agree, which we already do, test using RC binaries as soon as they appear stable enough.
( I used to develop in the kernel. We would have our subsystem (unit, alpha, beta, RC, and then Release levels) which then moved on to the greater kernel with all its moving parts as well. )
My statement about Ubuntu 24.04… BEFORE it was released
(Notice post date of April 1)
April 4, 2024 - The Ubuntu 24.04 Beta release will be publicly available; April 25, 2024 - Official Ubuntu 24.04 release date. Ubuntu 24.04 LTS will officially be released and made publicly available.Apr 2, 2024
I’ve seen releases get pushed back 2 days before scheduled date.
Therfore, as of April 1, to be runnin 24.04 (pre-release / beta) – is too early IMHO and why I cautioned.
As we found out… it broke a whole bunch of things … not just PMS
All said and done, we had a lot of changes on our end (including staffing) and have come a long way since then.
You seem to suggest Plex has any input to what Ubuntu releases and calls “stable”. Plex does not, they are an entirely independent entity.
If you don’t like what Ubuntu is calling stable, you should try taking it up that chain.
Does Plex only support Ubuntu? Seems pretty limiting to put a fix out that is targeting a kernel mainly for distros that stay cutting edge. Debian is a very popular distro and 6.7 is the latest kernel available (and only via backports).
We support Ubuntu & Debian as well as Redhat & Fedora.
We support various other distros through our docker image (which is Ubuntu runtime based).
I will ask again,
May I have:
I’m not ignoring you. My server has just been too busy to be able to get clean enough logs. I will post logs as soon as I can.
@ChuckPa I can confirm the issue persists for me and my Intel Arc GPU on Ubuntu Server 24.04 running kernel 6.8. HW Acceleration works fine as long as tone mapping is disabled. I don’t have logs for you yet but I will provide them tomorrow.
Thank you but there is no need.
Given PMS does not directly support the Arc GPUs, it must do so via the VA-API layer.
VA-API transcoding works for the same reason AMD GPUs can transcode – SDR content only.
There is no OpenCL support for the AMD nor is there for the Arc.
Each uses a different method…
To further complicate this, the 6.8 kernel had even more upstream changes
We now have Intel QSV transcoding and tonemapping working with the 6.8+ kernels.
We are looking at, and have plans, to make more sweeping changes to the transcoder underpinnings which will give us a lot of capabilities like AMD and Arc.
For now, there is no quick fix.
I hate to be that guy (because I’m not looking to move away from Plex), but is there a reason Plex isn’t able to support QSV on the Arc like Jellyfin has for over a year with almost no configuration at all? I just confirmed again it’s still working in Jellyfin on my test setup (Ubuntu 24.04, kernel 6.8, Intel Arc GPU).
I had to do no configuration for ARC to work with Plex.
Ubuntu 22.04.4, PlexInc official docker. It just works.
Added first a310 last october. Added a reloaded a fresh machine this past april or may.