Jump to content

NVENC/DEC Hardware Initilization Issues


DoctorZeus
Go to solution Solved by DoctorZeus,

Recommended Posts

DoctorZeus

Howdy,

I have had issues with this one for a while now and have been pretty stumped on how to solve it.

I keep getting multiple errors when emby tries to initialize hardware encoding/decoding and is subsequently not available because of this.

Using Arch Linux and I have checked with the systemd service file to confirm that it also adds the emby user to the "video" and "render" groups so it should have access.

I can also confirm that I can transcode outside of emby no problem using my graphics hardware.

I have attached my hardware detection logs, if anyone has any ideas that would be greatly appreciated!

Many Thanks

embyserver.txt

hardware_detection-63751813816.txt

Edited by DoctorZeus
Added Emby Server Logs As Well
Link to comment
Share on other sites

DoctorZeus
7 minutes ago, Luke said:

Hi there, please attach the emby server log as well. thanks.

Thanks for the reply, I have attached to original post.

Link to comment
Share on other sites

To rule out any permission issues, you could go to the Emby installation bin folder and run something like 

sudo ./emby-ffdetect -hide_banner -show_program_version -loglevel 48 -show_error -show_log 40 nvencdec -print_format json

 

Link to comment
Share on other sites

DoctorZeus
On 3/21/2021 at 2:48 PM, softworkz said:

To rule out any permission issues, you could go to the Emby installation bin folder and run something like 




sudo ./emby-ffdetect -hide_banner -show_program_version -loglevel 48 -show_error -show_log 40 nvencdec -print_format json

 

Please find attached and yes all NVIDIA drivers installed via the official arch repos.
Many Thanks!

embydetectout.txt

Link to comment
Share on other sites

Thanks. The detection run via sudo has successfully detected the Nvidia GPU, while it failed when run by Emby.

I don't know  arch Linux, so I can't tell exactly what's wrong, but it very much looks like a permissions problem.

Link to comment
Share on other sites

DoctorZeus

Thanks, what I thought as well.
It's actually setup and installed by the official package on the repos so I will see if I can report as a community bug after doing a bit of tweaking myself..

Edited by DoctorZeus
Quoted wrong response
Link to comment
Share on other sites

3 minutes ago, DoctorZeus said:

Thanks, what I thought as well.
It's actually setup and installed by the official package on the repos so I will see if I can report as a community bug after doing a bit of tweaking myself..

What were your results without sudo and when impersonating the Emby user?
No need to post the results - just let me know what worked and what didn't..

Edited by softworkz
Link to comment
Share on other sites

DoctorZeus
6 minutes ago, softworkz said:

What were your results without sudo and when impersonating the Emby user?
No need to post the results - just let me know what worked and what didn't..

The "emby-server" daemon is actually granted permissions to the "render" and "video" groups on runtime using the "SupplementaryGroups" flag in the service file.

Having said that actually sudoing into a shell for the emby user and running "ffdetect-emby" seems to initialize nvenc fine..

Link to comment
Share on other sites

3 minutes ago, DoctorZeus said:

The "emby-server" daemon is actually granted permissions to the "render" and "video" groups on runtime using the "SupplementaryGroups" flag in the service file.

Having said that actually sudoing into a shell for the emby user and running "ffdetect-emby" seems to initialize nvenc fine..

Inside the shell for the emby user, did you run with sudo or without?

Link to comment
Share on other sites

DoctorZeus
9 minutes ago, softworkz said:

Inside the shell for the emby user, did you run with sudo or without?

Sudoed into a shell for the emby user, didn't give it any additional permissions or do any additional sudoing inside of that.

Link to comment
Share on other sites

  • Solution
DoctorZeus

Ok I solved it.

The service has the argument "ReadWritePaths=-/dev/dri" seems to be the root cause, and removing it seems to restore transcoding.

Will query to the authors why that is.

Many thanks for your help though, beyond the call!

Edited by DoctorZeus
Link to comment
Share on other sites

23 minutes ago, DoctorZeus said:

Will query to the authors why that is but its possible its a typo.

Already did that. 

Thanks a lot for reporting!

Link to comment
Share on other sites

DoctorZeus
1 hour ago, alucryd said:

It does not: https://www.freedesktop.org/software/systemd/man/systemd.exec.html

Where did you get that information?

I meant indirectly but yes in hindsight could have been clearer.

I was thinking originally of another service that uses the " - " to remove the permission but yes your right the " - " actually just specifies to ignore if it doesn't exist..

Frankly that just adds more mystery to the problem though of why this causes this..

Edited by DoctorZeus
Link to comment
Share on other sites

alucryd

Does  the issue come up only on boot, or even if you restart it manually afterwards? Could be that your graphics device hasn't been fully initialized when emby starts. I know nvidia devices are troublesome for foldingathome for example, they initialize CUDA on demand, so when foldingathome first starts, they aren't available yet. Maybe something similar is happening here.

Link to comment
Share on other sites

DoctorZeus
10 hours ago, alucryd said:

Does  the issue come up only on boot, or even if you restart it manually afterwards? Could be that your graphics device hasn't been fully initialized when emby starts. I know nvidia devices are troublesome for foldingathome for example, they initialize CUDA on demand, so when foldingathome first starts, they aren't available yet. Maybe something similar is happening here.

Sadly yes still occurs after restarting manually.

Link to comment
Share on other sites

alucryd

I'm afraid I have no idea then:/ I ran this systemd service with an nvidia card for a couple years without issue, although I have now switched to amd. I never saw this issue mentioned before, there may be something specific to your particular system. You can override the directive permanently if you extend the systemd service, just create a file in /etc/systemd/system/emby-server.d/override.conf containing:

[Unit]
ReadWritePaths=/dev/dri

Then run systemctl daemon-reload and your fix won't be erased when you update the emby-server package.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...