[mythtv-users] Seek Table Question

Michael T. Dean mtdean at thirdcontact.com
Thu Jun 7 19:24:13 UTC 2007

On 06/07/2007 03:12 PM, Brian Walter wrote:
> Michael T. Dean wrote:
>> On 06/07/2007 03:00 PM, Brian Walter wrote:
>>> The sql server is not on the same system, and I run optimizedb every night.
>>> I'm thinking more along the lines of network issues.
>>> But thanks for the info.  I'll have to keep digging then.
>> Definitely possible.  Or, perhaps something else on the same computer as
>> MySQL is hogging CPU or I/O.
> Thanks!  BTW...is my assumption even possible?  That if *something* 
> clogs up/slows down the sql update, that that might overflow into a 
> glitch in the writing of the recording file?
> Just trying to get my head around the possibilities....

If the MySQL server's data files are on the same drive/volume (or even
possibly on the same bus) as the recording storage, then the SQL that
Myth issues could easily cause recording glitches.

If the MySQL server is running on a different system from the storage
and writing its data to a different drive, then the SQL that Myth issues
should not cause any harm to the recording itself.  However, if Myth is
unable to write the seektable information to the MySQL server, it's
possible that you could see issues during playback that are reminiscent
of the issues you could see from glitches in the recording.  However,
you're most likely to see these issues when seeking rather than when
playing the recording.  By playing back the recording with a non-Myth
application (i.e. MPlayer, xine, or Windows Media Player...), you can
determine whether the recording or the seektable data is corrupted.

If the recording file is corrupted and you're writing the recording to a
network-mounted drive, it's very likely a network issue (where network
issue includes everything from hardware to choice of network file system
to configuration of network filesystem).


More information about the mythtv-users mailing list