[mythtv] [mythtv-commits] Ticket #1404: Invalid file error at file

[Chris Pinkham]

> #1404: Invalid file error at file change with LiveTV

> Changes (by bobnvic at gmail.com):
 
>  Your assumption is incorrect. As stated, the frontend is streaming from
>  the SBE, the NFS share is not mounted on the frontend. The slave backend
>  is writing to an NFS share which is mounted with actimeo=0.

Yes, my fault, sorry about that.

This could be either database or fileserver related.  From looking at your
logs, it appears that it took 49 seconds for the old recording to end and the
new one to start:

2006-02-26 12:30:00.972 Chain: Appended at 5 '1025_20060226123000'

This is caused by line 4130 in tv_rec.cpp (tvchain->AppendNewProgram())

Then the next recording-related entry is 49 seconds later here:

2006-02-26 12:30:49.033 RecBase(/dev/video0): SetRingBuffer(0xb058d4c8) '/var/mythtv/tv/1025_20060226123000.mpg'

Then we have these:

2006-02-26 12:30:49.112 TVRec(3): SetFlags(RingBufferReady,) -> FrontendReady,RunMainLoop,CancelNextRecording,AskAllowRecording,RecorderRunning,RingBufferReady,
2006-02-26 12:30:49.585 TVRec(3): RingBufferChanged()

In MpegRecoder::SetNextRecording(), we save the positionmap to the
database then force the ringbuffer's writer to flush to disk.  The we
acquire the nextRingBufferLock and set the nextnextringbuffer.

The ringbuffer gets cutover at the next keyframe, and I doubt that was
49 seconds later, so it appears that the 49-second delay was inside of
MpegRecorder::SetNextRecording() either in writing the positionmap to
the database or in flushing the old ringbuffer data to the nfs server.
That is if I'm following this right, if not Daniel or Isaac will set
me straight. :)

Are you using NFS v3 with synchronous writes?  Do you see any odd
entries in you mysql or nfs server logs around the 12:30:00-12:30:49
timeframe to indicate that either was being hit hard around that time?

-- 
Chris