<div dir="ltr"><div dir="ltr">On Sat, Mar 2, 2024 at 11:31 PM Ian Evans <<a href="mailto:dheianevans@gmail.com">dheianevans@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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" target="_blank">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>
<ul><li>
<span>
<a><span>Total Cores</span></a>
</span>
<span>
4</span>
<br>
</li><li>
<span>
<a><span>Total Threads</span></a>
</span>
<span>
8</span>
<br>
</li><li>
<span>
<a><span>Max Turbo Frequency</span></a>
</span>
<span>
3.60 GHz</span>
<br>
</li><li>
<span>
<a><span>Intel® Turbo Boost Technology 2.0 Frequency<small><sup>‡</sup></small></span></a>
</span>
<span>
3.60 GHz</span>
<br>
</li><li>
<span>
<a><span>Processor Base Frequency</span></a>
</span>
<span>
2.60 GHz</span>
<br>
</li><li>
<span>
<a><span>Cache</span></a>
</span>
<span>
6 MB Intel® Smart Cache</span></li></ul></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></blockquote><div><br></div><div>An update. Went into setup and allowed commercial detection to start immediately. CPU setting was Low.</div><div><br></div><div>Created a 15 minute manual recording a few minutes away and allowed commercial detection for that recording. The recording started. <br></div><div><br></div><div>According to the queue it first looked up the metadata and then ran mythcommflag. According to top, load spiked to 3.97, and mythcommflag's CPU % was around 97%. During the whole 15 minutes of the recording it never got past "looking for logo:</div><div><br></div><div>When the recording ended, it finally started processing. Load dropped down to about 1.75 and CPU% for mythcommflag was around 37%. According to the job queue it was running at about 97.0251 fps.</div><div><br></div><div>Why would the logo detection spike so high?</div><div><br></div><div><br></div></div></div>