[mythtv-users] Running mythcommflag on another PC?

[Ian Evans]

On Wed, Mar 6, 2024, 4:16 p.m. Greg Oliver <oliver.greg at gmail.com> wrote:

> On Wed, Mar 6, 2024 at 1:39 PM Ian Evans <dheianevans at gmail.com> wrote:
>
>> On Sun, Mar 3, 2024, 12:37 a.m. Ian Evans <dheianevans at gmail.com> wrote:
>>
>>> On Sat, Mar 2, 2024 at 11:31 PM Ian Evans <dheianevans at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Mar 2, 2024 at 7:02 PM Stephen Worthington <
>>>> stephen_agent at jsw.gen.nz> wrote:
>>>>
>>>>> As for mythcommflag performance, for processors 10 years old or
>>>>> younger and not the super cheap variety, then they can normally do
>>>>> commflagging on one recording per CPU core/thread in real time.  So
>>>>> for a 4 core dual threaded CPU, you could do 8 mythcommflag processes
>>>>> simultaneously in real time as 8 recordings happen together.  The
>>>>> trick with real time commflagging is that it gets done in RAM, on the
>>>>> buffered recording data before it gets written to disk.  Once the data
>>>>> has been written to disk, reading it back again slows down
>>>>> commflagging, as there is then the problem of contention for the disk,
>>>>> with the heads having to move between recordings.  So you also need
>>>>> enough RAM, as well as the CPU resources.
>>>>>
>>>>> I gave up doing commflagging a long time ago as here in New Zealand,
>>>>> it never gave useful results.  So I have not tried commflagging with
>>>>> the current generations of CPU, which are much faster again than 10
>>>>> year old ones.  They may well be able to do more than one mythcommflag
>>>>> operation per CPU thread, maybe even three or four.
>>>>>
>>>>> I would recommend a starting position of one commflag operation per
>>>>> CPU core/thread being run on the main recording box, starting the
>>>>> commflagging when the recording starts.  Then just let any more
>>>>> simultaneous recordings that go over that limit have their
>>>>> commflagging queued to be done later.  There should not be any need to
>>>>> have another box doing commflagging unless you are recording 20 things
>>>>> at once all day.
>>>>
>>>>
>>>> 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.
>>>>
>>>> The backend is currently running on an old Toshiba Satellite laptop. It
>>>> has 8 gig of RAM and a i7-3720QM CPU.
>>>>
>>>> According to Intel ARK:
>>>>
>>>>    - Total Cores 4
>>>>    - Total Threads 8
>>>>    - Max Turbo Frequency 3.60 GHz
>>>>    - Intel® Turbo Boost Technology 2.0 Frequency‡ 3.60 GHz
>>>>    - Processor Base Frequency 2.60 GHz
>>>>    - Cache 6 MB Intel® Smart Cache
>>>>
>>>>
>>>> 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.
>>>>
>>>
>>> An update. Went into setup and allowed commercial detection to start
>>> immediately. CPU setting was Low.
>>>
>>> Created a 15 minute manual recording a few minutes away and allowed
>>> commercial detection for that recording. The recording started.
>>>
>>> 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:
>>>
>>> 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.
>>>
>>> Why would the logo detection spike so high?
>>>
>>>
>> What would you guys say is the minimum Intel/AMD generation for real-time
>> commercial flagging, because this i7-3720QM isn't cutting it.
>>
>> Thanks.
>>
>
> I am stabbing in the dark here because I haven not used MythTV in a few
> years, but real-time commflagging is very efficient (it comm flags as it
> records).  Your request to have commflagging on a separate machine (slave
> backend) basically (I think) disables that capability because it relies on
> the files to be written to disk before the slave actually has access to
> it.  This would greatly increase IO pressure too.
>
> Did you every try the immediate commercial detection setting without the
> slave?  I had a very old i7 (older than yours) that could comm detect 4
> ATSC recordings @ once without any load at all (well, not much).
>
> When you measure the load, is it in IOWait, or what?
>

Sorry... never actually got to using a slave. My temporary setup on
the i7-3720QM wasn't cutting it, so I was just tossing out an idea. The
spiked load was just the Load reading in top. The laptop was still pretty
responsive, but the fan was just howling like a banshee.

Of course, a laptop isn't the perfect airflow situation, so maybe I should
hold off on commflagging until Im using a better setup. : -)

I am curious why the real-time test took 15 high load minutes on "looking
for logo" before settling down and flagging at 90+ fps.

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20240306/df1be1f9/attachment-0001.htm>