Jump to content

NVENC Transcoding Not Doing Anything


Kirk137
 Share

Recommended Posts

Kirk137

Hi all,

 

I recently migrated my Emby server from a VM to a physical server so that I could take advantage of NVENC transcoding using a graphics card.  My physical server is running Emby 3.3.1.0-68.1 (latest from the repo), CentOS 7, and an nVidia GeForce GTX 950, with the latest nVidia drivers installed.

 

I enabled the hardware accelerated transcoding from the admin settings:
5b70f58feecdf_Screenshotat20180812220202

 

Unfortunately this has no effect.  When I play back a video, it's still transcoding using the CPU.  This is obvious both due to the CPU usage and because nvidia-smi shows no encoder usage.

[root@triton ~]# nvidia-smi -q -d UTILIZATION

==============NVSMI LOG==============

Timestamp                           : Sun Aug 12 22:03:23 2018
Driver Version                      : 390.77

Attached GPUs                       : 1
GPU 00000000:17:00.0
    Utilization
        Gpu                         : 0 %
        Memory                      : 0 %
        Encoder                     : 0 %
        Decoder                     : 0 %
    GPU Utilization Samples
        Duration                    : Not Found
        Number of Samples           : Not Found
        Max                         : Not Found
        Min                         : Not Found
        Avg                         : Not Found
    Memory Utilization Samples
        Duration                    : Not Found
        Number of Samples           : Not Found
        Max                         : Not Found
        Min                         : Not Found
        Avg                         : Not Found
    ENC Utilization Samples
        Duration                    : Not Found
        Number of Samples           : Not Found
        Max                         : Not Found
        Min                         : Not Found
        Avg                         : Not Found
    DEC Utilization Samples
        Duration                    : Not Found
        Number of Samples           : Not Found
        Max                         : Not Found
        Min                         : Not Found
        Avg                         : Not Found

[root@triton ~]# 

What's frustrating is, during my testing I had previously installed Emby 3.5.2.0 from the RPM download, and I did the same steps, and transcoding was working and I saw encoder usage on nvidia-smi.

 

Unfortunately because I migrated my metadata and users from another server running the repo version, my past attempt to migrate from 3.3 to 3.5 failed probably due to differences in the file structure, so that's why I'm still running 3.3 (the latest from the repo).

 

I'm not sure if my problem is because of 3.3 or because of something sticking in the configuration due to the migration or something.

 

 

Here is some environment information:

[root@triton ~]# cat /etc/*release
CentOS Linux release 7.5.1804 (Core) 
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.5.1804 (Core) 
CentOS Linux release 7.5.1804 (Core) 
[root@triton ~]# 
[root@triton ~]# lspci | grep NVIDIA
17:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 950] (rev a1)
17:00.1 Audio device: NVIDIA Corporation Device 0fba (rev a1)
[root@triton ~]# 
[root@triton ~]# uname -a
Linux triton 3.10.0-862.9.1.el7.x86_64 #1 SMP Mon Jul 16 16:29:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@triton ~]# 
[root@triton ~]# yum list installed | grep emby
emby-server.x86_64                    3.3.1.0-68.1                    @home_emby
embymagick.x86_64                     6.9.6+6-7.4                     @home_emby
libembysqlite3-0.x86_64               3.18.0+0-1.3                    @home_emby
mono-core.x86_64                      4.8.1.0-2.1                     @home_emby
mono-data.x86_64                      4.8.1.0-2.1                     @home_emby
mono-data-sqlite.x86_64               4.8.1.0-2.1                     @home_emby
mono-extras.x86_64                    4.8.1.0-2.1                     @home_emby
mono-mvc.x86_64                       4.8.1.0-2.1                     @home_emby
mono-wcf.x86_64                       4.8.1.0-2.1                     @home_emby
mono-web.x86_64                       4.8.1.0-2.1                     @home_emby
mono-winforms.x86_64                  4.8.1.0-2.1                     @home_emby
mono-winfxcore.x86_64                 4.8.1.0-2.1                     @home_emby
[root@triton ~]# 

Is it possible to tell from the transcoding log why NVENC did not start the encode and why it fell back to CPU?  Here is a sample log from the transcoder:

https://iota.lt/d/DnDUkVFytG/XWZtF07c.txt

 

Any ideas appreciated.... I had this working on a different Emby version with the same hardware so I know it's possible.

 

Thanks!

Link to comment
Share on other sites

Where did you get that ffmpeg build from? Is it even compiled with nvenc libraries?

 

I would use our new package with 3.5. With the older 3.3 you had to bring your own ffmpeg build and that pretty much makes you responsible for making sure it supports the features you need.

 

With newer versions we are supplying ffmpeg and the version we have has the Nvenc libraries included. Please let us know if this helps. Thanks !

Link to comment
Share on other sites

doonze

Use the backup/restore plugin. Backup your server. Switch over to the standalone version (the one you can download here and manually install). Then if you lose anything just restore your backup. 

 

The Standalone version is self contained, it keeps everything under Emby's control. It's all tested to work correctly together. The repo versions are more of an ad hoc approach, and leaves keeping everything up to date and working to the repo maintainers. I used the repo versions for years, but have switched to the standalone and have not been sorry.

 

The downside? No auto-updating.  I've written a script for that, and need beta testers to test if for me "in the wild". So if you're feeling adventurous, and want to be a guinea pig, check out my post below:

 

https://emby.media/community/index.php?/topic/61623-multi-distro-linux-python-auto-update-script-embyupdate/

 

And don't forget to uninstall your repo version first ("apt remove emby-server" or whatever your distro uses) so it doesn't try and update it next update! Ask me how I know.... 

Edited by doonze
Link to comment
Share on other sites

Kirk137

Where did you get that ffmpeg build from? Is it even compiled with nvenc libraries?

 

I would use our new package with 3.5. With the older 3.3 you had to bring your own ffmpeg build and that pretty much makes you responsible for making sure it supports the features you need.

 

With newer versions we are supplying ffmpeg and the version we have has the Nvenc libraries included. Please let us know if this helps. Thanks !

Oh, perhaps not.  It's an FFMPEG static build that I obtained at this site, which was linked from ffmpeg's download page.  These builds have always worked for me in the past with CPU encoding, and I didn't realize there were special requirements for the FFMPEG build to support NVENC.

 

 

Use the backup/restore plugin. Backup your server. Switch over to the standalone version (the one you can download here and manually install). Then if you lose anything just restore your backup. 

 

The Standalone version is self contained, it keeps everything under Emby's control. It's all tested to work correctly together. The repo versions are more of an ad hoc approach, and leaves keeping everything up to date and working to the repo maintainers. I used the repo versions for years, but have switched to the standalone and have not been sorry.

 

The downside? No auto-updating.  I've written a script for that, and need beta testers to test if for me "in the wild". So if you're feeling adventurous, and want to be a guinea pig, check out my post below:

 

https://emby.media/community/index.php?/topic/61623-multi-distro-linux-python-auto-update-script-embyupdate/

 

And don't forget to uninstall your repo version first ("apt remove emby-server" or whatever your distro uses) so it doesn't try and update it next update! Ask me how I know.... 

Does the backup/restore plugin backup metadata?  (cover art, identity of series, etc?)  That's basically the only data I care about at all.

 

I had just migrated this server from a previous server using rsync, and at some point last night, Emby decided to rescan my library or something and all of my library targets vanished.  For now I reverted back to my old server.  I don't know what happened with that honestly so I may rebuild this a third time and do what you've suggested.

 

With that plugin can I create a backup on version 3.3 and restore it on the 3.5 standalone version?  Will it preserve my metadata?

 

I am physically moving servers but the new server has the same NFS mount point mounted to the same mountpoint for the actual media files.

Link to comment
Share on other sites

Kirk137

Do you have local metadata saving to nfo files enabled?

Whatever the default behavior is.  I went to Library > Metadata and "NFO" is checked under Metadata Savers.

Link to comment
Share on other sites

Ok so the backup process doesn't backup metadata itself, however if you have nfo files in your media folders then that will serve as your backup.

 

Please let us know if this helps. Thanks.

Link to comment
Share on other sites

  • 4 weeks later...

Ok so the backup process doesn't backup metadata itself, however if you have nfo files in your media folders then that will serve as your backup.

 

Please let us know if this helps. Thanks.

Finally getting back to working on this, lol.

 

So I do have the NFO setting checked, but my metadata is not writing to my media folders.  My media folders are read-only on this server.

 

I believe the metadata is stored here?  /var/lib/emby-server/metadata/library

 

But somehow after I synced this over from the old server, Emby overwrote it or something, because after 1 night of working perfectly, the next day it trashed all of the metadata on the new server and all of the libraries disappeared.  I got frustrated and decided to revert to the old server for awhile, and now I'm coming back to look at this again and hopefully get this migration finished up.  In fact, somehow after this happened, even Emby's automatic population of covers on the new server is broken, leaving most media with no covers at all and only oddly deformed screenshots from the video file.

 

After I've manually rsynced the above path from the old server again tonight, the covers all appear to be back and correct.

 

I'll have to see if whatever automatic task broke this once breaks it again tomorrow or not.  If not then I can get back to the NVENC issue and try another FFMPEG binary... otherwise I may scrap the whole new server and reinstall and go with the newer Emby version with the ffmpeg bundled.

 

Incidentally.... if I upgrade to the latest (RPM) version of Emby should I be able to rsync /var/lib/emby-server/metadata/library to the new server from my Emby 3.3.1.0 instance?  Is that folder structure different at all?

Link to comment
Share on other sites

The only place nfo gets saved in is media folders, so if emby server only has read only access then it will not work.

 

Folder structure is the same in the latest version. Thanks.

Link to comment
Share on other sites

Ok so the backup process doesn't backup metadata itself, however if you have nfo files in your media folders then that will serve as your backup.

 

Please let us know if this helps. Thanks.

Alright, thanks for the clarification.  But what then is the purpose of this setting?

5b999a86af66a_Screenshotat20180912175927

Since I had the ability to turn this off, this led me to assume that I didn't need to give Emby write access to my media folders.

 

Emby is able to retain cover art and media metadata that persists across server reboots, despite having only read-only access to the media folders and this setting toggled off on the libraries.

Link to comment
Share on other sites

I responded based on the latest release of the server, and the settings have changed slightly. Yes you are right about that setting, disabling means the server won't need write access.

Link to comment
Share on other sites

  • 4 weeks later...
Kirk137

Just wanted to update here for anyone reading this in the future - I did get the NVENC working fine, all I had to do was install the latest RPM version of Emby as we discussed here.  The issue was probably with the ffmpeg binary I'd used in the older version without bundled ffmpeg.

 

I never did get the migration to happen, it was too frustrating seeing everything work great then seeing Emby blow it all away at the next library scan.  What I ended up doing was starting from scratch and fixing the broken covers for my obscure media manually.  This time I saved copies of the covers I replaced in case I ever have to do this again in the future.

 

Still not going to give Emby write access to my library, it's not practical with how my server is set up, but it seems to be working fine without it, it's still saving metadata somewhere.

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
 Share

×
×
  • Create New...