[mythtv-users] LiveTV stutter while in EPG/Guide

[Monkey Pet]

On Wed, Oct 24, 2012 at 7:43 AM, Matt Piermarini
<mattpiermarini at yahoo.com>wrote:

>
> On 10/24/2012 09:57 AM, Scott Harris wrote:
>
>> I'm working on wife factor here.. Live TV does work, with a couple
>>>>>> sub-second pauses here and there, but wife acceptable.  The problems
>>>>>> I'm
>>>>>> having is while watching liveTV, and I bring up the EPG, the
>>>>>> >>smaller TV
>>>>>> picture in the corner will stutter.  A couple seconds after bringing
>>>>>> up the
>>>>>> guide, it will be fine.  Then, after each up/down arrow press to
>>>>>> browse the
>>>>>> guide will result in the same stutter, level >>out, stutter, level
>>>>>> out,
>>>>>> stutter, level out, etc. It works, but is very annoying.
>>>>>>
>>>>>> This happens on both frontends: (core2duo/NV G210 and Nvidia ION --
>>>>>> both
>>>>>> using vdpau). -- HDHR Prime directly connected to backend. Tried both
>>>>>> .25
>>>>>> and .26.  I did NOT have this problem on .24. >>Happens on any VDPAU
>>>>>> profile.. happens on any content (1080i, standard-def (which actually
>>>>>> is
>>>>>> worse believe it or not)).
>>>>>>
>>>>>> Does anybody else see this, and if so, do you just deal with it?
>>>>>>
>>>>>>  This is not much help but I'm having the same issue too. 0.24 was
>>>>> fine
>>>>> but on 0.26 every time I press the mouse while the EPG is up the
>>>>> picture
>>>>> stutters. I kind of just deal with it but it's got to the stage >where
>>>>> I'm
>>>>> contemplating going back to 0.24 because it's so annoying.
>>>>>
>>>>
>>>>  Mark
>>>>>
>>>>
>>>> In 0.25, apparently code was changed so that every time you jump to a
>>>> new
>>>> channel (you'll notice there is no stutter if you scroll horizontally
>>>> across
>>>> the time), some stuff including a sql query is done to determine if the
>>>> channel you just navigated to would be tunable (i.e. it doesn't have a
>>>> scheduled recording with new free tuners, etc).  The "stuff" that
>>>> happens
>>>> causes the stutter while it processes.  I agree, it's annoying, but
>>>> apparently necessary.
>>>> ______________________________**_________________
>>>>
>>>>  I agree that it does more "work" when moving channel to channel in the
>>> guide, but I can't believe that it's so much as to cause the video to get
>>> starved for resources.. the CPU's are only at 5%.   The network might get
>>> saturated for the SQL queries, as it is streaming the video from the BE
>>> and
>>> the mysql engine is on that same backend. I'll check that.  Has anybody
>>> tried jumbo frames (MTU 9000)? Good/bad/no difference?
>>>
>>> Matt
>>>
>> All I can tell you is that was the explanation that I was given by
>> those "in the know" when I raised the issue when it appeared in 0.25.
>> Since I have no reason to doubt it, and it made sense (though
>> admittedly my first, unspoken thought was "then there must be a better
>> way to do it"), I never pursued it any further.  TBH, sadly Live TV
>> issues do not get much love (other than being told you're doing it
>> wrong if you're using Live TV, so avoid the issues by doing it
>> "right") ...
>> ______________________________**_________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://www.mythtv.org/mailman/**listinfo/mythtv-users<http://www.mythtv.org/mailman/listinfo/mythtv-users>
>>
>
> Funny -- Almost sounds like when I was told "I was holding it wrong" by
> Apple & the iPhone4 debacle.  It's too bad though -- there are some of us
> "old-timers" which still like to channel surf!
>

I don't channel surf (just too many damn channels to go through), but I
love LiveTV!  However, LiveTV doesn't seem to get any love around here.


>
> Thanks for the input though..
>
> Matt
>
> ______________________________**_________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/**listinfo/mythtv-users<http://www.mythtv.org/mailman/listinfo/mythtv-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20121024/bde71174/attachment.html>