Create Thumbnails Task is only using a fraction of available resources

[pclausen 44]

A couple of weeks ago, an update was pushed that triggered all my Roku thumbnails to be re-created.  I have about 80TB worth of media, so the process is taking a long time.  I'm currently at 87.9%, chipping away a few percentage points a day (the speed varies depending on which media library is currently being processed.

 

I'm curious why this process is not taking advantage of all my available resources.  Here's a view from Task Manager:

 

 

And resource monitor:

 

 

So it looks like only a single instance of ffmpeg is running, and it doesn't even saturate one logical core.  Disk I/O is also very low, not even hitting 10% on the volume being worked on.

 

If there a setting somewhere I can tweak to get this task to start using more of the available resources?

 

Thanks

Edited August 10, 2016 by pclausen

[lorac 118]

I also find that even if you stop the create thumbnail process it doesn't kill ffmpeg.

[pclausen 44]

I have found that ffmpeg goes away after killing a process that uses it (create thumbnail, a transcode session, etc), but it takes a good while, several minutes maybe longer.  I think it likes to complete operating on whatever file it has open before exiting.

[Luke 42085]

I also find that even if you stop the create thumbnail process it doesn't kill ffmpeg.

 

It stops the task at graceful stopping point, meaning, it allows the current process to finish but then won't launch any additional instances of ffmpeg.

[Luke 42085]

I will change the thread count from 1 to automatic on this operation but it might not make a difference because i'm not sure ffmpeg image extraction is optimized for multi-threading. but we'll see.

[pclausen 44]

Awesome Luke.  I switched to the latest Dev (3.1.6066.25698) and check out the performance difference:

 

 

And the speeds at which the source file is being processed:

 

 

So it went from reading at 5.6 MB/sec to 100 MB/sec.  An improvement of almost 18x!

[pclausen 44]

Hmm, looks like I spoke to soon.  It has now slowed down to running at the same speed as before, and there is no bif file for the title that was being worked on at great speed.

 

Here's the pertinent section from the log file:

2016-08-11 03:44:19.1452 Info App: Profile: Roku Thumbnails, Path: Z:\Blu-Ray\30 Days of Night (2007)\30 Days of Night.mkv, isEligibleForDirectPlay: False, isEligibleForDirectStream: True
2016-08-11 03:44:19.1452 Info App: Profile: Roku Thumbnails, No direct play profiles found for Path: Z:\Blu-Ray\30 Days of Night (2007)\30 Days of Night.mkv
2016-08-11 03:44:19.1452 Info App: Creating roku thumbnails at 320 width, for Z:\Blu-Ray\30 Days of Night (2007)\30 Days of Night.mkv
2016-08-11 03:44:19.1452 Info MediaEncoder: C:\Users\peter\AppData\Roaming\Emby-Server\ffmpeg\20160410\ffmpeg.exe -i file:"Z:\Blu-Ray\30 Days of Night (2007)\30 Days of Night.mkv" -threads 0 -v quiet -vf "fps=fps=1/10,scale=min(iw\,320):trunc(ow/dar/2)*2" -f image2 "C:\Users\peter\AppData\Roaming\Emby-Server\cache\cache\temp\deff6d3114cf41d19748324047513bfa\img_%05d.jpg"
2016-08-11 03:47:19.1620 Info MediaEncoder: Killing ffmpeg process
2016-08-11 03:47:20.1626 Error MediaEncoder: ffmpeg image extraction failed for file:"Z:\Blu-Ray\30 Days of Night (2007)\30 Days of Night.mkv"
2016-08-11 03:47:20.2252 Error App: Error creating roku thumbnails for 30 Days of Night
	*** Error Report ***
	Version: 3.1.6066.25698
	Command line: C:\Users\peter\AppData\Roaming\Emby-Server\System\MediaBrowser.ServerApplication.exe
	Operating system: Microsoft Windows NT 6.2.9200.0
	Processor count: 28
	64-Bit OS: True
	64-Bit Process: True
	Program data path: C:\Users\peter\AppData\Roaming\Emby-Server
	Application Path: C:\Users\peter\AppData\Roaming\Emby-Server\System\MediaBrowser.ServerApplication.exe
	ffmpeg image extraction failed for file:"Z:\Blu-Ray\30 Days of Night (2007)\30 Days of Night.mkv"
	System.ApplicationException
	   at MediaBrowser.MediaEncoding.Encoder.MediaEncoder.<ExtractVideoImagesOnInterval>d__48.MoveNext()
	--- End of stack trace from previous location where exception was thrown ---
	   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
	   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
	   at RokuMetadata.Drawing.VideoProcessor.<CreateBif>d__16.MoveNext()
	--- End of stack trace from previous location where exception was thrown ---
	   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
	   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
	   at RokuMetadata.Drawing.VideoProcessor.<Run>d__7.MoveNext()
	--- End of stack trace from previous location where exception was thrown ---
	   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
	   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
	   at RokuMetadata.Drawing.VideoProcessor.<Run>d__6.MoveNext()
	--- End of stack trace from previous location where exception was thrown ---
	   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
	   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
	   at RokuMetadata.ScheduledTasks.RokuScheduledTask.<Execute>d__11.MoveNext()

I'm also seeing a lot "Bitrate exceeds DirectPlay limit" in the log for a lot of titles.  When I go look at the folder, there is already a .bif file.  Would it not be more intuitive for the log message to be something along the lines of "skipping, .bif file already exists"?

Edited August 11, 2016 by pclausen

[pclausen 44]

Speed has picked back up again.  ffmpeg is reading at around 55 MB/sec at the moment and CPU utilization is around 40%.  Maybe it just had to find its "groove".

[Luke 42085]

bravo