transcoding, seeking and orphan ffmpeg processes consuming CPU

[lifespeed 42]

I am CPU transcoding to Android mobile client over the internet (LTE).  When I seek using the scrub bar server CPU utilization goes from 90% to 100% and stays there for at least several minutes.  When I look at the running processes in task manager, I see a second ffmpeg process was started, I presume to support transcoding from the new seek location.  Yet the previous ffmpeg process was not shut down - the two ffmpeg processes are hogging 100% CPU, at 50% each.  When I stop playing the Android client one ffmpeg process stops, while the second ffmpeg lingers at 10% CPU for several minutes before terminating.

 

I did check transcoding without seeking through the movie, in this case the server and transcoding are well behaved with ffmpeg using the typical 90% CPU (i7-6800K, slow and 22 quality settings).  If I stop playing at the client, the single ffmpeg process terminates immediately.

 

It seems the server would be much more responsive if the unneeded second ffmpeg process were terminated promptly.  I suspect this unnecessary server load is degrading the user experience.  Perhaps it is not that hard to track down and resolve?  Please let me know if there is anything further I can do to help troubleshoot besides the attached logs.  Android client is 3.8.x.x beta within the past two days, not sure where to find the version number in the app.

 

Thanks!

server-63633825041.txt

ffmpeg-transcode-4099a602-80de-4868-a1c2-6ced9ef179f6.txt

ffmpeg-transcode-ccf995f1-dae1-460d-974a-1cdca25b27f8.txt

ffmpeg-transcode-4b804d44-38b4-437a-98b8-c9572c19c3ae.txt

[Luke 39685]

Why do you think they were orphan processes? Each time you seeked, these showed up in the server log:

2017-06-23 14:35:04.1815 Info App: Stopping ffmpeg process with q command for C:\Users\Clay\AppData\Roaming\Emby-Server\transcoding-temp\b2ba8e65f5316701ad403d4ec460c994.mkv
2017-06-23 14:35:04.9697 Info App: FFMpeg exited with code 0

[lifespeed 42]

 

Why do you think they were orphan processes? Each time you seeked, these showed up in the server log:

2017-06-23 14:35:04.1815 Info App: Stopping ffmpeg process with q command for C:\Users\Clay\AppData\Roaming\Emby-Server\transcoding-temp\b2ba8e65f5316701ad403d4ec460c994.mkv
2017-06-23 14:35:04.9697 Info App: FFMpeg exited with code 0

When I stopped play in the client without seeking, ffmpeg on the server shut down instantly.  When I seeked, a second ffmpeg process would start, and the first would stay running for several minutes.  I am assuming that there should not be two ffmpeg processes running for a long time, certainly this maxes the CPU.

 

Have you tried reproducing this?  It is easy for me to recreate, but I don't know if it happens across all windows 10 Emby server and Android mobile client setups.

[Luke 39685]

I cannot reproduce it, no. When I seek the first one is terminated quickly.

[lifespeed 42]

If I use an iPad instead of Android mobile, both set to 1080p 5Mbps stream rate in the client, there is no second ffmpeg process on the server bogging down the CPU while seeking.  In fact, when using the iPad client the CPU utilization is about 60% compare to 90% for the android client even though the same bitrate is requested.

 

The second ffmpeg process runs for about 5 minutes before stopping.  Maybe this is related to the something in the android client?

[Luke 39685]

Thanks for the feedback. We will do more testing.