[mythtv-users] Live TV playback frustration
Adrian Saul
sgtbundy at gmail.com
Fri Aug 24 11:56:21 UTC 2012
On 23/08/2012 5:32 AM, Michael T. Dean wrote:
>
> They are supposed to be MyISAM. That's as defined in our schema
> creation code.
It was probably an artefact of moving the DB off the linux mythtv box
and onto Solaris. I setup the database software and restored the
database from an SQL dump, but neglected to setup any particular tuning
(my.cnf). The database was created a long time ago (0.13 era I think)
and been through various upgrades and migrations. I have never modified
the schema though.
>
>>
>> So while I could not reproduce it, I took a guess that table locking
>> on a 9.1M row table was not going to be great under MyISAM, and
>> started converting most of my tables to InnoDB and in the process
>> tweaked the ZFS setup underneath it to match recommendations for
>> InnoDB. I had the memory for it so I also setup the database with a
>> 512M InnoDB cache. That seemed to resolve the lagging start issue on
>> the second frontend and also seems to make things a lot snappier in
>> general.
>>
>> I also revisited my NFS setup. To try and fix the second frontend
>> being unable to change channels (loses the jump buffer) I tried
>> setting actimeo=0, but that just caused LiveTV to stutter and fail
>> constantly. In desperation I switched back to NFSv4 with no special
>> tuning and it all just started working properly.
>>
>> So, thanks for the all the suggestions. Seems like it was my setup.
>
> FWIW, I have 1936 programs, using 8.9 TB (2 months 25 days 21 hrs 31
> mins) with 15M rows in recordedseek and am still using the
> supported-for-MythTV storage engine (MyISAM) and get wonderful
> performance. It takes less than 1s to enter Watch Recordings on my
> system--I generally use the Watch Recordings jump point from within
> Watch Recordings to get back to the top of my recording list because
> it's /much/ faster than scrolling.
I was surprised that change made the difference it did. As mentioned,
direct queries and generally everything in the frontends was fine except
for those stalls around starting playback of a recording and the various
timeout errors that popped up watching in progress recordings or live TV.
>
> Note that in messing with the schema, you're potentially creating a
> problem for yourself in the future--upgrades may fail, such as when we
> convert everyone to InnoDB.
Well, I basically all I did switched any substantial table engine to
InnoDB, no schema modifications. Hopefully any upgrades in future
would handle the case that the engine was already set to InnoDB.
>
> Generally, we recommend that you don't mess with the schema. Chances
> are the problem was is elsewhere and you've only just covered up one
> appearance of a symptom of that problem.
Well, post upgrading to 0.26 the only two changes I made that resulted
in the problems going away were the InnoDB switch, and changing the NFS
mounts to NFSv4 with default options. I had previously used NFSv4
before so I suspect the issues I was trying to fix were really caused by
the MySQL setup. The fact I can now not worry about crashing my wifes
frontend when I start a recording or hearing her frustrated at constant
crashes is enough for me - if I covered up the real problem its not
bothering me now.
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
More information about the mythtv-users
mailing list