10479 3 Posted June 1, 2020 Share Posted June 1, 2020 Emby Server version: 4.4.2.0 and Premier Status Active System info: Arch Linux, kernel 5.6.15 Nvidia Driver version: 440.82-18 Packages related to hardware installed: nvidia, nvidia-utils, intel-media-sdk, intel-media-driver, intel-gmmlib So I have ended up rebuilding my server over the weekend to change some things around and went with a fresh install of the same version of emby that I was running before (4.4.2.0). 4.4.3.0 is not available yet. After setting everything up, Emby does not detect Nvidia hardware acceleration. After countless hours of searching and probing, at random, I stopped the emby-server.service, ran the command I found in the logs - /usr/bin/ffdetect-emby -hide_banner -show_program_version -loglevel 48 -show_error -show_log 40 nvencdec -print_format json After running that command and then restarting the service, Nvidia's options show up under hardware transcoding and do work. Ultimately, I've found that I don't have to run that entire command. Just running ffdetect-emby nvenc and so on will sort it as well. Here's logs for embyserver.txt and hardware_detection.txt for both before manually running the command and after to hopefully ID what is going on here. embyserver.txt fresh start - no hw accel hardware_detection.txt fresh start - no hw accel And after stopping the service, running ffdetect-emby and starting the service embyserver.txt after running command hardware_detection.txt after running command As soon as I reboot, Nvidia's transcoding is lost until I repeat the process of stopping, running ffdetect-emby and starting emby again. Any other info that is needed, just let me know and I will provide it. Thanks Link to comment Share on other sites More sharing options...
Luke 36886 Posted June 1, 2020 Share Posted June 1, 2020 Hi there, did you follow our hardware acceleration setup guide? https://support.emby.media/support/solutions/articles/44001160148-hardware-acceleration-overview Link to comment Share on other sites More sharing options...
10479 3 Posted June 1, 2020 Author Share Posted June 1, 2020 Yes. Link to comment Share on other sites More sharing options...
Luke 36886 Posted June 2, 2020 Share Posted June 2, 2020 Is emby starting automatically after your reboot? Link to comment Share on other sites More sharing options...
10479 3 Posted June 2, 2020 Author Share Posted June 2, 2020 Yeah. It starts up and doesn't throw any errors. It functions in its entirety outside of nvidia support when it starts up. Link to comment Share on other sites More sharing options...
Luke 36886 Posted June 2, 2020 Share Posted June 2, 2020 As a test, can you try disabling that and then starting it manually? Link to comment Share on other sites More sharing options...
10479 3 Posted June 2, 2020 Author Share Posted June 2, 2020 Sure. I disabled it, restarted the server and then started it back up manually and experience the same results. Here's the journal output for what it's worth - https://pastebin.com/ct2Pfrw0 Link to comment Share on other sites More sharing options...
10479 3 Posted June 2, 2020 Author Share Posted June 2, 2020 In the mean time, I've just created a service to run `ffdetect-emby nvenc` prior to starting emby. It's not ideal, but at least I don't have to babysit it. There is a substantial difference between the released systemd service file and what is used in Arch. I'm wondering if the new systemd service options work because the server was upgraded in place or something similar? Version 4.4 switched to DynamicUser via systemd, which has a lot more restrictions, but does have the proper permissions to allow access to the /dev/dri directory. Link to comment Share on other sites More sharing options...
10479 3 Posted June 7, 2020 Author Share Posted June 7, 2020 For what it's worth, I tried upgrading to the Arch Linux community testing version 4.4.2.0-1 and lost all transcoding entirely. I couldn't get it to show up under any circumstances. I have ended up going back to 4.4.0.40 to the pre-DynamicUser version where transcoding works as expected. Link to comment Share on other sites More sharing options...
Solution 10479 3 Posted August 9, 2020 Author Solution Share Posted August 9, 2020 4.5.0.16 beta also resolves this problem as well. Living the high life now. If it returns once this version reaches stable on Arch Linux, then it is highly likely that it has to do with the way the package is managed now. Link to comment Share on other sites More sharing options...
Luke 36886 Posted August 9, 2020 Share Posted August 9, 2020 Thanks for the feedback. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now