new nvidia drivers issue

[MisterAngelus 7]

I convert all my content to hevc using Emby and my Geforce 1650.

 

So today nvidia came out with new drivers 445.75- so I upgraded the drivers.... After doing so the GPU  encoding in Emby stopped working. 

So I went back to previous driver 442.74 and  the GPU encoding started working

 

So something messed up with the drivers

 

Anybody else seeing anything similar

Edited March 23, 2020 by MisterAngelus

[Luke 40064]

Hi, what does "stopped working" mean?

[MisterAngelus 7]

would no longer use GPU  for conversion  just  used CPU... But going back to previous drivers  made it use GPU  again  so it's not an emby issue something with the new driver

[MisterAngelus 7]

Apparently there's an issue with the new driver that effects FPS  would that also effect converting video?

[Luke 40064]

Can we look at an example? Thanks.

[MisterAngelus 7]

I no longer have the driver installed so i can't  run a currant test but i can attach the log you'll have to look through where it starts using cpu for conversion

embyserver.txt

[softworkz 4566]

@@MisterAngelus - Do you still have the ffmpeg logs?

 

@@Luke - Quite a number of unrelated errors in that log.

[MisterAngelus 7]

No but if you want you can download the nvidia drivers that were causing the issue 445.75-desktop-win10-64bit-international-dch-whql-g

 

issue went away once i uninstalled those drivers tho

Edited March 24, 2020 by MisterAngelus

[softworkz 4566]

I can't. My current Nvidia GPU has different latest drivers.

 

I think we'll just wait and see whether the issue persists in subsequent updates.

[MisterAngelus 7]

So  a new version of the drivers came out today - 445.87-desktop-win10-64bit-international-dch-whql-g so I installed it

 

has the same issue I mentioned above  still does not use the GPU to convert still not an Emby issue but mentioning it for others

 

but still uses CPU to convert

 

I had to revert to previous drivers 442.74-desktop-win10-64bit-international-dch-whql-g and it started using the GPU again

 

 

however during my test with the new drivers   445.87-desktop-win10-64bit-international-dch-whql-g  before uninstalled them and went back 

 

I did  grab the ffmpeg-transcode which @@softworkz wanted to look at

 

attached below 

ffmpeg-transcode-f60ef298-c8b1-4556-96ba-d6cfe4c92320_1.txt

[Luke 40064]

Has there been a driver update to resolve this?

[MisterAngelus 7]

the transcode log above was taken with the latest drivers before i uninstalled them and put back the previous drivers 

 

it was using CPU so i put back the old drivers and  it went  back to using GPU

 

 

So to my knowledge it's not fixed

Edited May 11, 2020 by MisterAngelus

[MisterAngelus 7]

update

 

the new driver came out today 446.14-desktop-win10-64bit-international-dch-whql-g

 

Same issue though

 

I have not downgraded yet

 

it still uses CPU and not gpu

 

can't figure out if there's a setting I need to change

 

I just know it works fine if i downgrade the driver

embyserver.txt

ffmpeg-transcode-adb6bfe3-2b95-445e-82bd-239699e2a884_1.txt

[softworkz 4566]

@@MisterAngelus - This is all about conversion, not playback, right?

I wouldn't recommend using Emby for doing full conversion of a library. It's just not tuned well enough to do this, no matter whether using software or hardware encoding.

[MisterAngelus 7]

playback is fine and and i'm not using it for a full library just the occasional episodes worked fine before when i had the old driver

 

do the logs tell you anything?

[softworkz 4566]

There seems to be a problem with the detection of supported HEVC encoding levels:

Encoder NVENC GeForce GTX 1650 - H.265 (HEVC)
        Adapter #0: 'GeForce GTX 1650' ComputeCapability: 7.5
        Frame Sizes: max 8192x8192 - Width Alignment: 2 - Height Alignment: 2
        Color Formats: NV12, P010, CUDA, YUV420P
        Profiles: Main Profile (Level 2 (Main)), Main 10 Profile (Level 2 (Main)), Range Extension (REXT) (Level 2 (Main))

Level 2 is detected incorrectly.

 

And that's why it doesn't get used:

NoMatch Encoder does not support the minimum required encoding level (HevcMainTierLevel41)
NoMatch Encoder does not match

What would be a great help would be the hw detection logs: one from where it's working and the other one from where it's not working.

[MisterAngelus 7]

did you want me to downgrade the driver back to the one that will encode now?

hardware_detection-63726188948.txt

ffmpeg-transcode-0e878aca-f976-4cee-9ebc-d2f209f21b56_1.txt

embyserver.txt

[softworkz 4566]

did you want me to downgrade the driver back to the one that will encode now?

 

That would be great. You might want to do that anyway to get it working until we'll be able to provide a fix.

[MisterAngelus 7]

ok here is the logs with it working

embyserver.txt

hardware_detection-63726191299.txt

ffmpeg-transcode-33eb5f44-5546-45cf-bff0-46e6a3b1171e_1.txt

[MisterAngelus 7]

so I'm curious is it an emby issue or an issue with the NVIDIA driver?

[softworkz 4566]

Thanks a lot, there's in fact a difference in the supported levels that Nvidia reports:

 

 

 

The right side is correct (Level 6.2), the left side doesn't make sense.

 

I'll think we'll have to report that to Nvidia as a bug..

[MisterAngelus 7]

I'm not experienced enough to know how to word that email  is that something emby would report to nvidia  or me?

[softworkz 4566]

No, I'll do this. We'll wait a bit though, because often, those bugs get fixed anyway, and getting heard by them takes a bit of effort and requires to ring certain bells..

[softworkz 4566]

Please feel free to remind me in a while!

[MisterAngelus 7]

Good luck its been in the last 3 drivers  how ever old this thread is...

 

Anyway thanks so much for your help