[mythtv-users] NVP: prebuffering pause -- what does it mean, really?

[Mike Perkins]

Willy Boyd wrote:
> On 3/17/07, Willy Boyd <willyboyd at gmail.com> wrote:
>> At this point I have had liveTV running for almost 11 hours straight.
>> I have been asleep most of that time, but in the mythfrontend log
>> (back to "normal" log level, no switches), I see that it went from
>> 12:30AM until 10:50AM with no messages -- which is when I changed the
>> channel, and did get one pair of "prebuffering pause / Prebuffer: wait
>> timed out 10 times" messages.  No visible hiccup though, and I'm going
>> to leave it here a few more hours and see how it plays.
>>
>> Last night I turned GLX back on (because it hadn't helped), and I
>> tuned my mysql config.  I think this may have been what really helped,
>> but we'll see.  This is what I added to the mysqld section of
>> /etc/my.cnf (based on what I found searching the list archive):
>>
>> key_buffer = 16M
>> max_allowed_packet = 8M
>> table_cache = 128
>> sort_buffer_size = 16M
>> net_buffer_length = 8M
>> thread_cache_size = 4
>> query_cache_type = 1
>> query_cache_size = 4M
>>
>> As a side effect, this makes mythweb much speedier due to query
>> caching.  But only time will tell if this is the true fix for my
>> freezing.  OH, and I checked temps, and my cores never go above 48
>> celcius during playback.  So I ran a myth svn compile, and they maxed
>> at 58 celsius, tops.  And this is still with cpuspeed disabled.
>>
> 
> Just replying to myself here to followup.  The same continued
> throughout the weekend -- we had liveTV going for close to 24 hours as
> of Saturday, and off and on Sunday.  The only time I saw the
> pause/timeout messages was immediately after a channel change, with no
> visible hiccup.  Then it would continue on just fine until another
> channel change (i.e., no problem across program changes).
> 
> I can't say *for sure* that the cpuspeed governor being off has no
> effect, because though I did experience the one crash after disabling
> it -- that filled my log with "LiveTV forcing JumpTo 1" messages -- I
> had to delete that 1.7GB logfile because I got scared that there was 0
> bytes left on my root partition.  So I really don't know what happened
> there.  I'm leaving cpuspeed off for good measure -- at least for a
> few days then I might test with it on again.
> 
> However, the mysql tuning can only be a good thing regardless, and I
> put more weight on that being the big helper.  I consider it something
> that "fixes the symptoms", but not necessarily a cure.  My last
> hardware was much weaker, and I never knew about mysql tweaking, yet
> it played SD like a champ.  This setup is much beefier.  Something has
> changed in code, that is either less efficient or just does more work
> than before (I basically upgraded everything, I consider this
> basically a new install).  I'm happy with things as they are now, and
> looking forward to HD!
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
> 
The reason you get the problem after changing channels in LiveTV mode is 
because the back end is closing one file and opening another...writing 
the data to disk, making new directory entries, updating the MySQL 
database etc. I usually get (now) a single hiccup about 2 secs after a 
new channel starts, which is when I assume the disk I/O is getting done.

However, I used to get this a lot with both Live TV and watching 
recordings. I have separate BE & FE machines. To try to narrow down the 
problem, I dug the BE out of it's cupboard and ran a frontend on it. No 
pauses. Not the hardware then. Having a spare capture card, I stuck that 
in my frontend, ran mythtv-setup and made it a slave backend - with 
storage in the same directory on the master machine via an NFS mount. 
With mythbackend running on my frontend machine, no pauses when watching 
Live TV off any tuner in either machine. So, not the frontend hardware 
either. If I try to watch a recording from the BE when one of the tuners 
on the BE is recording, no problem. If the tuner in my frontend is 
recording, on or two pauses.

I reckon therefore it's something network related. The presence of the 
slave backend, even though it's never used, seems to cause sufficient 
traffic on the network to keep everything greased enough to work 
properly. If I stop the slave backend, the pauses begin again.

Oh, and I haven't tuned my mysql setup. Might try that later.

Mike Perkins