[mythtv-users] Recording failed, but the backend didn't figure that out...
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>
> >> On Mon, Jul 30, 2012 at 8:51 PM, Jason Gillis <spuppet at comcast.net>
> >>> 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
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.
> mythtv-users mailing list
> mythtv-users at mythtv.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-users