<div class="gmail_quote">On Wed, Mar 5, 2008 at 4:25 PM, Gareth Glaccum <<a href="mailto:gareth.glaccum@btopenworld.com">gareth.glaccum@btopenworld.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d"><br>----- Original Message -----<br>From: <<a href="mailto:greg@nodecam.com">greg@nodecam.com</a>><br>>On my system (one firewire tuner, one PVR 250) I could cause problems by<br>>recording HD, playing back the same HD stream on a delay and recording SD<br>
>at the same time. As soon as I put in a new disk and separated recordings<br>>from database/logging, the problems went away.<br><br></div>That doesn't really make sense. Logging and database access is a minimum in<br>
the situation you desribed (EIT scanning is about it I think), just moving<br>the logs and database should have made little difference really.<br>Ok, if you are running more than just myth, a lot of logging and seperate<br>
database accesses in the background then this would make a difference.</blockquote>
<div> </div>
<div>Myth writes *alot* of data for the seektables when recording. The commflag process reads that as well as your playback so when you start to get a handful of recordings, especially HD where the bitrates are higher, the database gets hit pretty hard.</div>
<div> </div>
<div>Kevin</div></div>