[mythtv-users] NVP: prebuffering pause -- what does it mean, really?
Mike Perkins
mikep at randomtraveller.org.uk
Mon Mar 19 14:29:17 UTC 2007
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
More information about the mythtv-users
mailing list