[mythtv-users] Recording failed, but the backend didn't figure that out...

Fa fayoeu at gmail.com
Wed Sep 5 06:44:24 UTC 2012

On Tue, Sep 4, 2012 at 10:12 PM, Jason Gillis <spuppet at comcast.net> wrote:

> On Sep 4, 2012, at 5:15 PM, Phil Bridges wrote:
> > On Sun, Aug 5, 2012 at 11:16 PM, Phil Bridges <gravityhammer at gmail.com>
> wrote:
> >> On Mon, Jul 30, 2012 at 8:51 PM, Jason Gillis <spuppet at comcast.net>
> wrote:
> >>> Hi all,
> >>>
> >>> I've been trying to record as much of the Olympics coverage that NBC
> decides that I'm able to handle.  This has been up to four simultaneous
> recordings, and has put some pretty good strain on my storage array at
> certain times of day when I'm doing other things with it.
> >>>
> >>> I noticed this morning that when a schedule file system consistency
> check kicked off on the array at 7:00am (normally a fine time to do that),
> I got the following in the backend logs:
> >>>
> >>>
> >>
> >> I'm having a similar thing happen.  I was recording NBC's Olympics
> >> coverage tonight, along with two other channels.  All three were
> >> recording on my master backend, but it determined to record all three
> >> files to my slave backend's drives.  Althought I'm running a gigabit
> >> network, the two 9 o'clock programs errored out about 9:20.  The
> >> frontend didn't indicate the recordings were incomplete - they said
> >> they were x GB (7 or so).
> >
> > Once again, this happened during a football game recording last night.
> > Very disappointed.
> I haven't seen this happen since around the time I originally posted, so
> it's a concern for me, but hasn't been a pressing issue.  It also doesn't
> help that I don't have a reliable way to reproduce it, which would be the
> first step in being able to get help from the devs to track this issue down.
> I've been pretty careful since then, though, to try to reduce any
> instances of high disk activity to avoid the problem.  I suppose it might
> be reproducible if I nail my array with activity...  I'll see if I can find
> some time this weekend to abuse things other than my landscaping.
> To any of the dev types out there:  What's a good first guess at the
> appropriate flags for log output to try testing with?  I'd like to avoid a
> lot of cycles of going back for more if it can be avoided.  :)

I saw this patch: http://code.mythtv.org/trac/ticket/11061

Patch to improve ThreadedFileWriter performance. The attached patch does
two things:

   1. Drops data instead of giving up forever if the ThreadedFileWriter? buffer
   fills up. So you may have a glitch instead of a truncated recording.
   2. Removes the wait in DiskLoop?() if the write succeeds. This has a
   huge impact in keeping the buffer from filling up.

> Thanks,
> J
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120904/64bb41c7/attachment-0001.html>

More information about the mythtv-users mailing list