[mythtv-users] Live TV playback frustration
Michael T. Dean
mtdean at thirdcontact.com
Wed Aug 22 19:32:15 UTC 2012
On 08/19/2012 07:54 AM, Adrian Saul wrote:
> On 19/08/2012 2:37 AM, Adrian Saul wrote:
>
>> There is some lag on the playback startup and that occasionally
>> affects the other frontend too - so far the only thing in the logs is
>> time taking to do "SyncPositionMap" - which is odd because following
>> the code and doing SQL behind the query completes instantly when I
>> test it but in the logs I can see multiple instances where it takes
>> 13 seconds or more. Might take a closer look at what the database
>> is doing because the code shows nothing else that would block this.
>>
> So - for all my confidence in my infrastructure I took a look at the
> database to see what might cause this query to take so long. Any
> time I manually tested it, the performance was fine - near instant
> response. When I took a look at the tables I realised some things:
>
> - I have 1500+ recordings
> - Those recordings have 9.1M rows in the "recordedseek" table which is
> queried by SyncPositionMap.
> - Those tables were all on MyISAM tables from when I exported the
> database myself from Linux to Solaris.... doh
They are supposed to be MyISAM. That's as defined in our schema
creation code.
>
> 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.
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.
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.
Mike
More information about the mythtv-users
mailing list