[mythtv] Why are there so many instances of recordedseek?

[Steve E]

I ran iotop and watched it at the top of the hour. When the frontend
playback paused for 4 seconds, msqld jumped to the top of the
process list, using 98% of the I/O for roughly 4 seconds. So, it
does seem to be some MYSQL operation which is introducing these
delays for me.

I've got no hourly cron jobs.

I'll try applying some of the suggested MYSQL tuning changes to
see if they will help.

    Thanks,

    - Steve

On 04/21/2015 09:13 AM, Lennart Sorensen wrote:
> On Tue, Apr 21, 2015 at 10:11:24AM -0400, Michael T. Dean wrote:
>> Ah, nevermind--just saw that sentence in your original post.  It
>> does sound like another process or an I/O starvation thing, like
>> Richard suggested.  Also check your cron jobs to see if one of them
>> may be causing issues.
> I encountered issues at the top of the hour in the past when the scheduler
> was deciding what to do next, which didn't get along well with trying
> to read other data from the database and putting mpeg data onto the disk
> from the current recording.
>
> My rather overkill solution was to move mysql to SSD and leave the
> recordings on normal harddisks.  This made mysql MUCH happier given seek
> time went away and it wasn't sharing the filesystem with the recordings
> anymore.
>