[mythtv] [mythtv-commits] Ticket #8962: playbackbox.cpp:extract_job_state() inefficient
lsorense at csclub.uwaterloo.ca
Thu May 7 14:12:44 UTC 2015
On Thu, May 07, 2015 at 06:18:33AM -0700, Jim Stichnoth wrote:
> On Wed, May 6, 2015 at 2:12 PM, Yeechang Lee <ylee at columbia.edu> wrote:
> > Jim Stichnoth <jstichnoth@?> wrote on code.mythtv.org:
> > > This is essentially a cherry-pick of b43b11ca.
> > Jim, thank you very much for your work on #8962. I am still on 0.26
> > but your 0.27 backport applies to it, and on my older frontend makes a
> > *very* noticeable difference when entering and, especially, scrolling
> > through Watch Recordings. I have not noticed any delay from the
> > background jobqueue reload.
> That's good to hear! I'm actually a bit surprised to hear that it makes
> any substantial difference on *entering* the Watch Recordings screen, since
> pretty much all that can be done there was done in #10161 which was in
> 0.26. An BTW, I think I have noticed a once-every-15-seconds flicker of
> the screen while a recording listed on the screen is in-progress, but
> likely the flicker was there before this change (but maybe more frequent).
I applied the patch to my 0.27 frontend yesterday. So far it seems
to have made navigating around the recordings screen much much more
responsive. Previously it would often hang for seconds at a time when
you moved to a new entry.
I do run the connection between the frontend and backend over 802.11n
5GHz, and it is sometimes a bit flacky, but I frequently have been
rebooting the machine just to get the menu response back to something
sane. And the frontend machine is a 6GB Core i7-920, so it is NOT under
powered (the backend is more insanely overkill).
So far the patch appears to be making a huge difference, but I will keep
an eye on it for a few days to see if it has actually elliminated the
degradation in menu performance that was happening after a few hours
More information about the mythtv-dev