<br><br><div class="gmail_quote">On Tue, Sep 4, 2012 at 10:12 PM, Jason Gillis <span dir="ltr"><<a href="mailto:spuppet@comcast.net" target="_blank">spuppet@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Sep 4, 2012, at 5:15 PM, Phil Bridges wrote:<br>
<br>
> On Sun, Aug 5, 2012 at 11:16 PM, Phil Bridges <<a href="mailto:gravityhammer@gmail.com">gravityhammer@gmail.com</a>> wrote:<br>
>> On Mon, Jul 30, 2012 at 8:51 PM, Jason Gillis <<a href="mailto:spuppet@comcast.net">spuppet@comcast.net</a>> wrote:<br>
>>> Hi all,<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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:<br>
>>><br>
>>><br>
>><br>
</div><div class="im">>> I'm having a similar thing happen. I was recording NBC's Olympics<br>
>> coverage tonight, along with two other channels. All three were<br>
>> recording on my master backend, but it determined to record all three<br>
>> files to my slave backend's drives. Althought I'm running a gigabit<br>
>> network, the two 9 o'clock programs errored out about 9:20. The<br>
>> frontend didn't indicate the recordings were incomplete - they said<br>
>> they were x GB (7 or so).<br>
><br>
> Once again, this happened during a football game recording last night.<br>
> Very disappointed.<br>
<br>
</div>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.<br>
<br>
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.<br>
<br>
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. :)<br></blockquote>
<div><br></div><div>I saw this patch: <a href="http://code.mythtv.org/trac/ticket/11061">http://code.mythtv.org/trac/ticket/11061</a></div><div><br>Patch to improve ThreadedFileWriter performance. <span style="background-color:rgb(255,255,221);font-family:Verdana,Arial,'Bitstream Vera Sans',Helvetica,sans-serif;font-size:13px">The attached patch does two things:</span></div>
<div><ol style="font-family:Verdana,Arial,'Bitstream Vera Sans',Helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,221)"><li>Drops data instead of giving up forever if the <a class="missing wiki" style="color:rgb(153,153,136)">ThreadedFileWriter?</a> buffer fills up. So you may have a glitch instead of a truncated recording.</li>
<li>Removes the wait in <a class="missing wiki" style="color:rgb(153,153,136)">DiskLoop?</a>() if the write succeeds. This has a huge impact in keeping the buffer from filling up.</li></ol></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
<div class="HOEnZb"><div class="h5">J<br>
<br>
_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br>
<a href="http://www.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://www.mythtv.org/mailman/listinfo/mythtv-users</a><br>
</div></div></blockquote></div><br>