[mythtv] [mythtv-commits] Ticket #3350: Threaded Preview Gen does not use qmap index consistently
danielk at cuymedia.net
Thu Apr 26 19:28:13 UTC 2007
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
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.
More information about the mythtv-dev