<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 2, 2024 at 7:02 PM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As for mythcommflag performance, for processors 10 years old or<br>
younger and not the super cheap variety, then they can normally do<br>
commflagging on one recording per CPU core/thread in real time. So<br>
for a 4 core dual threaded CPU, you could do 8 mythcommflag processes<br>
simultaneously in real time as 8 recordings happen together. The<br>
trick with real time commflagging is that it gets done in RAM, on the<br>
buffered recording data before it gets written to disk. Once the data<br>
has been written to disk, reading it back again slows down<br>
commflagging, as there is then the problem of contention for the disk,<br>
with the heads having to move between recordings. So you also need<br>
enough RAM, as well as the CPU resources.<br>
<br>
I gave up doing commflagging a long time ago as here in New Zealand,<br>
it never gave useful results. So I have not tried commflagging with<br>
the current generations of CPU, which are much faster again than 10<br>
year old ones. They may well be able to do more than one mythcommflag<br>
operation per CPU thread, maybe even three or four.<br>
<br>
I would recommend a starting position of one commflag operation per<br>
CPU core/thread being run on the main recording box, starting the<br>
commflagging when the recording starts. Then just let any more<br>
simultaneous recordings that go over that limit have their<br>
commflagging queued to be done later. There should not be any need to<br>
have another box doing commflagging unless you are recording 20 things<br>
at once all day.</blockquote><br><div>Just a quick background. My wife and I are currently working on another place and I've just MacGyver'd a temporary setup so we'd have a PVR and I could tiner with v34.</div><div><br></div><div>The backend is currently running on an old Toshiba Satellite laptop. It has 8 gig of RAM and a i7-3720QM CPU. </div><div><br></div><div>According to Intel ARK:</div><div>
<li>
<span class="gmail-label">
<a class="gmail-view-modal gmail-info-modal gmail-ark-accessible-color"><span>Total Cores</span></a>
</span>
<span class="gmail-value">
4</span>
<br>
</li><li>
<span class="gmail-label">
<a class="gmail-view-modal gmail-info-modal gmail-ark-accessible-color"><span>Total Threads</span></a>
</span>
<span class="gmail-value">
8</span>
<br>
</li><li>
<span class="gmail-label">
<a class="gmail-view-modal gmail-info-modal gmail-ark-accessible-color"><span>Max Turbo Frequency</span></a>
</span>
<span class="gmail-value">
3.60 GHz</span>
<br>
</li><li>
<span class="gmail-label">
<a class="gmail-view-modal gmail-info-modal gmail-ark-accessible-color"><span>Intel® Turbo Boost Technology 2.0 Frequency<small><sup>‡</sup></small></span></a>
</span>
<span class="gmail-value">
3.60 GHz</span>
<br>
</li><li>
<span class="gmail-label">
<a class="gmail-view-modal gmail-info-modal gmail-ark-accessible-color"><span>Processor Base Frequency</span></a>
</span>
<span class="gmail-value">
2.60 GHz</span>
<br>
</li><li>
<span class="gmail-label">
<a class="gmail-view-modal gmail-info-modal gmail-ark-accessible-color"><span>Cache</span></a>
</span>
<span class="gmail-value">
6 MB Intel® Smart Cache</span></li></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">When I tried running commercial detection a few months ago, I remember the load spiking to 2.00. Can't remember if I had that running post recording while there were other recordings. I may have not set it for real-time detection thinking a laptop couldn't handle it. I'll have to change the setup when my the SVU marathon is over.<br></div><div class="gmail_quote"><div> </div></div></div>