Improve Preview Generation

[danielk]

TODO's

• Implement FILO ordering for preview generation
• Break preview generation out into a seperate process, to avoid segfaults bringing down the whole app
• Allow user control over where a preview is generated (backend, frontend, both) and limit the number of previews generation processes in flight at any point in time.

[danielk]

(In [13835]) Refs #3361. Exit more quickly after the 5th failed attempt to generate preview, and also only try five times when not using threaded preview.

[danielk]

Runs preview generation in separate process to isolate ffmpeg segfaults, so far remote previews are only partially supported.

[danielk]

Adds priority queue for preview generation and a maximum number of previews to generate at once (2). When the same preview is requested again it goes to the top of the queue..

[danielk]

Updated patch, starts extending the protocol to allow for different sized previews

[danielk]

Makes remote previews and screen grabs work...

[danielk]

(In [15027]) Refs #3361. Don't try to load nonexistant icons..

I noticed this when working on the preview generation. ChannelInfo::LoadIcon?() was attempting to load icons even if the iconpath was empty. This results in a lot of unneeded chatter between the backend and frontend. I only noticed this because I thought a storage group helper function I had added was failing to find valid files, but it turned out to be an existing problem.

[danielk]

(In [15028]) Refs #3361. Adds a little error condition debugging and error resiliance to the remotefile FileTransfer? handling in RemoteFile? class.

[danielk]

(In [15029]) Refs #3361. Improves Preview Generation.

• Implements a priority queue for preview generation and limits the total number of in-flight preview generation threads.
• Runs preview generator in a separate process so that an ffmpeg crash can't take down the backend or frontend we're using.

Currently the number of preview generation threads is limited to two by the 'previewGeneratorMaxRunning' variable. I haven't yet implemented the third todo, adding user control over various aspects of the preview generation processing.

Note: This also extends the screen shot code to work with remote backends, and fixes a race condition that caused this to crash sometimes. However unless both the backend and frontend are updated to this revision a remote 'screen shot' will just return a copy of the preview image.

[sphery <mtdean@…>]

The attached patch, mythtv-find_file_for_preview_gen.patch , modifies the Storage Group changes committed in [15029] based on the suggestion from Chris Pinkham at ​http://www.gossamer-threads.com/lists/mythtv/dev/303576#303576 . I think the changes are as he suggested and fit in well with the preview generator changes in [15029], but I'm happy to make additional changes as necessary.

Without the patch, going to the MythWeb Recorded Programs page takes forever and results in a huge CPU usage spike (mythbackend was running at 100% on my Athlon XP 2400+ (load average > 6) for so long that I just restarted it; on Chris Petersen's quad-core (Core 2?) backend, it was taking 400% and recovered after a few minutes). Individual preview generation jobs seem to work without too much issue before the patch; however, requesting a large number of previews simultaneously overwhelms mythbackend because of the recursive, recursive searches.

[danielk]

(In [15145]) Refs #3361. Reworks the preview generator's use of storage groups so as to avoid recursive searches and hence use less CPU. This also implements some cleanups in storagegroup.{cpp,h} after running them by Chris Pinkham.

[danielk]

Closing, the only remaining issue has it's own ticket #3353.