[mythtv-users] Running mythcommflag on another PC?

Greg Oliver oliver.greg at gmail.com
Wed Mar 6 21:15:35 UTC 2024


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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20240306/ae62e602/attachment.htm>


More information about the mythtv-users mailing list