[mythtv] [mythtv-commits] Ticket #3350: Threaded Preview Gen does not use qmap index consistently

Chris Pinkham cpinkham at bc2va.org
Thu Apr 26 19:03:42 UTC 2007

* On Thu Apr 26, 2007 at 12:00:28PM -0400, Daniel Kristjansson wrote:
> Ideally we should have an set a numeric limit on the number
> of previews either the frontend or backend should do at a time;
> say b2f1 on a balanced system with the drive on the backend,
> b3f0 on a system where the frontend is slow and/or only has
> access to recordings through the network, b0f4 where the backend
> is slow and the frontend is fast and has direct access to the
> files.

A limit on the number may be good but I'm not sure if it needs to
be that high.  If we queue the requests and process them in a
FILO order then we could get by with 2 at the most probably.
The recording we scrolled over 3 UP-arrows back doesn't matter
as much as the one we just scrolled onto, so we just process the
newest ones in the queue first.  Running too many at a time
could actually hurt performance because we're competing for
resources to generate a preview now that we won't even view
anytime soon because the user has gone on down the list.

> Another thing that has been bugging me about the preview
> generator on the backend is that it can take down the whole
> backend when ffmpeg segfaults when processing a broken
> MPEG-2 file (DTV). I think we should spawn a separate process
> to generate a preview on the backend since a backend crash
> is so much worse than a frontend crash (you lose recordings,
> and you may not notice for a while that the backend is gone).

This is one of the reasons I broke out mythcommflag into a
separate executable a long time ago.  I didn't want flagging
to be able to take down the backend.  Some people might like
the ability to run:

mythblah -c chanid -s startime -f framenum -o /path/to/snapshot.png


More information about the mythtv-dev mailing list