[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