Problems with transcoding after upgrade to 4.8.10

[yocker 1247]

After having updated to the latest version i'm having problems with transcoding.

While tone mapping works it seems very pale in comparison to the last version.
CPU usage have gone up a lot, this might be a good thing though as it could be working faster and not have a bottleneck somewhere but the extra amount of CPU usage is worrying.

ffmpeg-transcode-4e516f4a-b2f8-4a4d-bed4-839843b10206_1.txt hardware_detection-63863340420.txt embyserver-63863342373.txt

[Gilgamesh_48 1240]

I do not think you are at "the latest version:

My release server is currently at: Version 4.8.9.0

That could be at least part of the issue, maybe.

 

[Sluflyer06 0]

42 minutes ago, Gilgamesh_48 said:

I do not think you are at "the latest version:

My release server is currently at: Version 4.8.9.0

That could be at least part of the issue, maybe.

 

My dashboard is telling me 4.8.10 is available.

[Happy2Play 9780]

Yes 4.8.10.0 is the latest release as of Today.

• Fix hardware transcoding regression on some Linux platforms

 

But nothing stands out in the logs to me as it is being done in hardware.

 

[Gilgamesh_48 1240]

I see. I misread the title and, using only my mind, added an extra dot to make it. (4.8.1.0) 

Now I fee I am behind  

 

[Gilgamesh_48 1240]

2 minutes ago, Happy2Play said:

Yes 4.8.10.0 is the latest release as of Today.

• Fix hardware transcoding regression on some Linux platforms

 

But nothing stands out in the logs to me as it is being done in hardware.

 

Is this not the "General/Windows" server forum? 

I do not expect to see Linux messages here. I was all ready to wonder why I was not offered an upgrade and then I see we are talking about Linux. It is unkind to fool old folks that way.  

[Happy2Play 9780]

3 minutes ago, Gilgamesh_48 said:

Is this not the "General/Windows" server forum? 

I do not expect to see Linux messages here. I was all ready to wonder why I was not offered an upgrade and then I see we are talking about Linux. It is unkind to fool old folks that way.  

A fix for that platform but versioning affecting everyone.  But yes in general this is not a Window specific issue.  And this section sort of becomes the catch all.  As it potentinatlly need to be in Docker topic.

[yocker 1247]

2 hours ago, Happy2Play said:

Yes 4.8.10.0 is the latest release as of Today.

• Fix hardware transcoding regression on some Linux platforms

 

But nothing stands out in the logs to me as it is being done in hardware.

 

I can't find anything out of the ordinary in the logs either. I went out of my way to make sure audio was being directly played and no subs as well to not effect the CPU.
Still i'm having a very high CPU usage when transcoding is done. Plus the video looking a little "pale".

 

[yocker 1247]

Found out the reason for the pale colors.
Best way i can describe it is that when playing a movie that's being transcoded in firefox the video gets pale when the control menu pops but but everything goes back to normal when the menu goes away.

Still can't find a reason for the higher than usual CPU usage but it doesn't bother me that much.

Anyway, as far as i'm concerned it's working now.

[jim2cpu 1]

I wouldn't mind bringing this thread back to life... I just noticed that hardware transcoding wasn't working. With apple devices around the house, not a lot of transcoding happens so I didn't notice.

I'm on TrueNAS Scale 24.10.02 and Emby 4.8.10.0.

At first I assumed this may have something to do with TrueNAS Scale's transition to docker in 24.10. Futzed around at the OS for awhile and then on a whim decided to just install Plex really quickly to see if hardware transcoding worked there... and it worked flawlessly, immediately.

So back to Emby... anyone else still struggling with this following recent updates? Happy to share logs if needed.

[jim2cpu 1]

Bit more detail... I zipped through the hardware detection log and see this message:

"Message": "Failed to open the drm device /dev/dri/renderD128"

From inside the container shell, I chmod 777 -R /dev/dri and then restarted Emby from the admin panel (not the container) and hardware transcode options came back immediately.

[yocker 1247]

24 minutes ago, jim2cpu said:

Bit more detail... I zipped through the hardware detection log and see this message:

"Message": "Failed to open the drm device /dev/dri/renderD128"

From inside the container shell, I chmod 777 -R /dev/dri and then restarted Emby from the admin panel (not the container) and hardware transcode options came back immediately.

So Emby didn't have read permissions to the drivers?

I'm not 100% sure how the user, UID, permissions work but would be where i would start looking for a solution.

[Luke 42077]

@jim2cpu?

[jim2cpu 1]

Looking for a status update from me? My workaround is sound, but if I restart the container, the permissions revert and hardware transcoding does not work. Manually adjusting the permissions to /dev/dri inside the container via the console corrects the issue.

I can't imagine this is an issue with the TrueNAS scale host because as I said above, when installing the Plex container it's hardware transcoding worked immediately out of the box with no changes to the host or the container configuration/permissions.

[yocker 1247]

2 hours ago, jim2cpu said:

Looking for a status update from me? My workaround is sound, but if I restart the container, the permissions revert and hardware transcoding does not work. Manually adjusting the permissions to /dev/dri inside the container via the console corrects the issue.

I can't imagine this is an issue with the TrueNAS scale host because as I said above, when installing the Plex container it's hardware transcoding worked immediately out of the box with no changes to the host or the container configuration/permissions.

Sounds like changing the permissions outside the docker container will work.

/dev/dri is not part of Emby it self so you will be able to do it in a terminal from Truenas it self. (I don't use Truenas so don't know how to access the terminal there, sorry)

[jim2cpu 1]

I'd rather not make a change on the host to address something that appears to have changed with the container image. I recognize that a 777 on /dev/dri isn't the end of the world from a security perspective but in posting here I was hoping to get this on a track where the underlying root cause was identified. I assume something happened with recent updates... especially given: "Fix hardware transcoding regression on some Linux platforms" being listed in the release notes for 4.8.10.0.

[yocker 1247]

1 hour ago, jim2cpu said:

I'd rather not make a change on the host to address something that appears to have changed with the container image. I recognize that a 777 on /dev/dri isn't the end of the world from a security perspective but in posting here I was hoping to get this on a track where the underlying root cause was identified. I assume something happened with recent updates... especially given: "Fix hardware transcoding regression on some Linux platforms" being listed in the release notes for 4.8.10.0.

If Emby doesn't have permissions to the /dev/dri files it won't be able to read them no matter what the developers do.
Emby should have permission to start with so might just be a user permission error made when making the docker container.

Maybe it can be fixed with changing user in the docker container.
This can be done by editing the Emby docker container and changing the following variables:

UID which is the user ID
GID which is the group ID

Change them to follow what you find in TrueNAS WebUI Credentials --> "UID" column.

Please note!!!
I have never changed user in Emby so i don't know if it will have any impact on Emby it self like it loosing it's meta data and you having to rescan everything again.
You can maybe ask someone from the developer team about that in a new thread as your problem doesn't really fit this thread.

I don't see why it shouldn't have permission in the first place, unless you have specifically locked the files down.

 

[Q-Droid 989]

The UID doesn't need to change. The GID is the relevant value here and the GIDLIST in the docker compose/run for Emby is how you ensure the right access is given to the runtime user for access to the graphics devices.

 

 

Edited November 18, 2024 by Q-Droid

[yocker 1247]

58 minutes ago, Q-Droid said:

The UID doesn't need to change. The GID is the relevant value here and the GIDLIST in the docker compose/run for Emby is how you ensure the right access is given to the runtime user for access to the graphics devices.

 

 

Thank you!
That actually makes sense now that i think about it.

Love to learn new stuff!

 

[Endless 0]

I have this same problem. What exactly was the resolution ?

[jim2cpu 1]

Ultimately I did end up changing the permissions to /dev/dri on the host system (Truenas Scale) to 777 recursively.

[DAVe3283 7]

I tend to agree with jim2cpu that changing the host permissions isn't the ideal solution. I think that something is wrong with the docker config for Emby in the official app.

Especially since if I install the Jellyfin app on Scale, it just works with no permissions changes needed anywhere.

Edited December 3, 2024 by DAVe3283
Fix wording

[yocker 1247]

2 hours ago, DAVe3283 said:

I tend to agree with jim2cpu that changing the host permissions isn't the ideal solution. I think that something is wrong with the docker config for Emby in the official app.

Especially since if I install the Jellyfin app on Scale, it just works with no permissions changes needed anywhere.

I suspect that it's also possible to just make a new user group for the ID used.

[Q-Droid 989]

This is not an Emby issue. Truenas scale users should talk to whomever bundles Emby for that platform and ask them to include the runtime groups needed for access to the graphics devices out of the box. I don't think the Emby team is involved in the TrueNAS app catalog maintenance. 

It sounds to me like the person handling JF for TrueNAS did the same for their app. 

 

Edited December 3, 2024 by Q-Droid