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

[Daniel Kristjansson]

On Thu, 2007-04-26 at 15:03 -0400, Chris Pinkham wrote:

> 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.

Makes sense, the FILO would really help with this from a UI
responsiveness standpoint; the next preview would always be
what is currently selected. Maybe a tiny delay before the
second one is kicked off would help too, then if you scroll
quickly a preview generation would catch up more quickly.

> Running too many at a time could actually hurt performance

Yep, my FEs are pretty powerful (AMD64 X2 4200+ with untold
gigs of RAM) so I can delete all the previews and scroll
through all my recordings without a hickup, but a VIA 1Ghz
with 512 MB would be a completely different matter.

> > generator on the backend is that it can take down the whole
> > backend when ffmpeg segfaults when processing a broken
> 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

That could be useful, especially if you could specify a
file as well, instead of just a chanid & starttime. 
Then I could generate previews for the old PSAs I've
downloaded from archive.org without arcane mplayer
tricks.

I've taken the liberty of creating a task ticket #3361
with these todo's. I'll be working on the multirec and
mythtv-vid tickets for a while, but I'll put this in my
bin for when I'm done-with or temporarily-sick-of those.
If you, or anyone else, would like to work on any of
those tasks that would be great, but I'll get to this
before too long if no one else picks it up.

-- Daniel