<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On Aug 16, 2013, at 17:23, Greg Cope <<a href="mailto:gregcope@gmail.com">gregcope@gmail.com</a>> wrote:</div><div><br></div><blockquote type="cite"><div><div dir="ltr">On 16 August 2013 21:43, Raymond Wagner <span dir="ltr"><<a href="mailto:raymond@wagnerrp.com" target="_blank">raymond@wagnerrp.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Aug 16, 2013, at 16:14, Tyler T <<a href="mailto:tylernt@gmail.com">tylernt@gmail.com</a>> wrote:<br></div>
<br>
Depending on your circumstances, such as a handful of broadcast channels with a handful of recording rules, a low end ARM would work just fine. When you have lots of recording rules, or a large backlog of past recordings for duplicate matching, an ARM isn't going to cut it, and even an Atom is likely going to delay long enough that you're going to have delayed or dropped recordings.<br>
</blockquote><div><br></div><div>I have lots (1000?) of recordings (SD) and my Atom does fine.</div></div></div></div></div></blockquote><br><div>The more old recordings you have, the longer the scheduler query takes doing duplicate matching. Check your backend logs and see how long your scheduler runs are. Usually somewhere around a minute is where problems start to manifest.</div></body></html>