Emby was utilizing 100% of my Ryzen 3700x CPU

[ShadowKindjal 21]

I'm wondering what situation would cause my emby server to peg my CPU at 100% utilization. The server was completely unresponsive so I forced a docker restart of that specific container and my utilization immediately dropped below 10%. I caught a glimpse of some of the tasks in htop before restarting the server and it seems that ffmpeg processes were hitting the cpu hard. That has me confused because I thought my gpu would be processing those requests. I've attached a log for reference. The end of the log is the server restart.

embyserver (1).txt

[Happy2Play 9780]

Where there corresponding ffmpeg logs?

FYI Emby currently does not completely sanitize logs so you need to look at these.

Host=, X-Forwarded-For=, X-Forwarded-Host=, X-Forwarded-Server=, X-Original-URL=, X-Real-IP=

@Luke

[ShadowKindjal 21]

4 minutes ago, Happy2Play said:

Where there corresponding ffmpeg logs?

I've posted some of the FFMPEG logs at that time. I also noticed that there was a hardware detection log with the following line. Could this be the issue?

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

 

 

4 minutes ago, Happy2Play said:

FYI Emby currently does not completely sanitize logs so you need to look at these.

Host=, X-Forwarded-For=, X-Forwarded-Host=, X-Forwarded-Server=, X-Original-URL=, X-Real-IP=

@Luke

Thank you for the info. I'll remove the log files once Luke is able to review the issue and sanitize them in the future.

ffmpeg-directstream-f62798fe-74ba-4639-8a89-fc7664754294_1.txt ffmpeg-transcode-54a1ca38-b3b3-477c-89c9-dc29ff1b2846_1.txt ffmpeg-transcode-d3e03344-015d-4ca9-85f6-32d1e2e3ee6c_1.txt ffmpeg-transcode-93a89e45-5737-4f13-9ff9-7dd62106306c_1.txt hardware_detection-63815119204.txt ffmpeg-transcode-24f39bcc-5c9b-42dc-a857-baf14f975b96_1.txt

[Happy2Play 9780]

The devs will have to comment more as it is specific to ffmpeg.

21:53:48.651 [AVHWDeviceContext @ 0x1c7c4c0] cu->cuInit(0) failed -> CUDA_ERROR_NO_DEVICE: no CUDA-capable device is detected
21:53:48.651 Device creation failed: -542398533.
21:53:48.651 [hevc @ 0x1cb9e40] No device available for decoder: device type cuda needed for codec hevc.
21:53:48.651 Stream mapping:
21:53:48.651   Stream #0:0 (hevc) -> superscale_cuda:default (graph 0)
21:53:48.651   Stream #0:2 (pgssub) -> scale:default (graph 0)
21:53:48.651   overlay:default (graph 0) -> Stream #0:0 (h264_nvenc)
21:53:48.651   Stream #0:1 -> #0:1 (dts (dca) -> ac3 (native))
21:53:48.651 Device setup failed for decoder on input stream #0:0 : Generic error in an external library


Info    Previous transcoding attempt failed. Falling back to software transcoding.

Looks similar to the issues in beta branch.

Does changing the Decoder to CUVID make a difference?

[ShadowKindjal 21]

1 minute ago, Happy2Play said:

The devs will have to comment more as it is specific to ffmpeg.

21:53:48.651 [AVHWDeviceContext @ 0x1c7c4c0] cu->cuInit(0) failed -> CUDA_ERROR_NO_DEVICE: no CUDA-capable device is detected
21:53:48.651 Device creation failed: -542398533.
21:53:48.651 [hevc @ 0x1cb9e40] No device available for decoder: device type cuda needed for codec hevc.
21:53:48.651 Stream mapping:
21:53:48.651   Stream #0:0 (hevc) -> superscale_cuda:default (graph 0)
21:53:48.651   Stream #0:2 (pgssub) -> scale:default (graph 0)
21:53:48.651   overlay:default (graph 0) -> Stream #0:0 (h264_nvenc)
21:53:48.651   Stream #0:1 -> #0:1 (dts (dca) -> ac3 (native))
21:53:48.651 Device setup failed for decoder on input stream #0:0 : Generic error in an external library


Info    Previous transcoding attempt failed. Falling back to software transcoding.

Looks similar to the issues in beta branch.

Does changing the Decoder to CUVID make a difference?

I could change the decoder to CUVID but i don't have an immediate way to verify if the issue is resolved. It seems to fall back to software encoding (based on the log line you found) at sporadically. CUVID is also not available for all media codecs.

[Luke 42078]

Well one of the examples is having to burn in PGS subtitles. That's going to be a very intensive process.

I would also suggest putting these back to defaults:

Warning EncoderParametersH264LibX.Preset: Original: veryfast Actual: fast
Warning EncoderParametersH264LibX.ConstantRateFactor: Original: 23 Actual: 25

 

[ShadowKindjal 21]

44 minutes ago, Luke said:

Well one of the examples is having to burn in PGS subtitles. That's going to be a very intensive process.

But would that be a reason for it to fall back to software encoding?

44 minutes ago, Luke said:

I would also suggest putting these back to defaults:

Warning EncoderParametersH264LibX.Preset: Original: veryfast Actual: fast
Warning EncoderParametersH264LibX.ConstantRateFactor: Original: 23 Actual: 25

 

Done. Thank you 

[Luke 42078]

Hi, has this helped?

[ShadowKindjal 21]

As of right now the issue has not reoccurred but i also don't know how i would test my system since it seemed to happen sporadically