[mythtv-users] Commercial Detection during recording

Joseph Fry joe at thefrys.com
Mon Mar 11 20:47:25 UTC 2013


> I'm afraid I tried 3 or 4 times but could not make out what you are
> trying to say above.
>
> > my fear is that enabling multiple threads would thrash my drives when I
> am
> > recording 3 shows, watching one, and doing 2 comflags;
>
> You seem to be missing the point.  Adding additional parallel-running
> commflag jobs, to the limit of your CPU's ability to keep them going
> real-time, actually reduces overall I/O, not increases it.  That is, you
> can add as many parallel-running commflag jobs as your CPU has the
> ability to keep going real-time without adding any I/O load over doing
> no commflagging at all.
>
> One optimization that I don't know is the BE code already is that when
> the number of parallel commflag jobs is below the number of concurrent
> recordings, the excess commflag jobs should be queued at a lower
> priority (in the queue, not CPU scheduling priority here) than future
> real-time possible commflag jobs.
>
> For example if your schedule was:
>
> 8pm - 9pm:
> show 1
> show 2
> show 3
>
> 9pm - 10pm
> show 4
> show 5
> show 6
>
> and your maximum number of parallel jobs is 2, then the order should be:
> 1 & 2 (both real-time)
> 4 & 5 (both real-time)
> 3 & 6 (both non-real-time, after 10pm)
>
> rather than a more naive (i.e. FIFO) schedule of:
>
> 1 & 2 (both real-time)
> 3 & 4 (1 real-time, 1 non-real-time)
> 6 & 6 (both non-real-time)
>
> Cheers,
> b.


I think you understood what I was saying without realizing it.  I used the
example of two recordings with only a single comflag job allowed.  But the
same would apply with 3 recordings and two jobs allowed.   I record 3 or 4
things simultaneously almost every night.

Now, I am pretty sure my CPU could handle 2 comflag jobs in realtime, but
on busy nights when I'm recording 4 shows and watching 1, I'm not so sure
that my IO would keep up.  I recall trying it briefly a year or so ago and
it worked well only when the recordings/comflag jobs were spread out neatly
across my 3 drives; suggesting that it may have been disk IO rather than
CPU.

Unfortunately, there is no way to tell the system to reduce the number of
comflag jobs when there are a high number of recordings, so I leave it at 1
job at a time.  But if I knew it would only commflag shows that were
currently recording during those times, and the cache would be used to
eliminate/reduce the disk IO.. then I suspect that I could set it higher.

What I hoped to encourage discussion on is exactly what you suggested.  If
# recordings > # allowed comflag jobs, place current recordings at the top
of the queue rather than the end so that as one realtime comflag job
completes another starts.  Lower priority recordings would wait until # of
recordings becomes < # of allowed jobs before commflagging.

Essentially I would love to be able to start watching the latest episode of
Walking Dead 30 minutes after it starts and know it will have been
comflagged because it currently the highest priority recording, and my
system always comflags current recordings before it starts on past
recordings.

Make sense?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130311/db02e170/attachment.html>


More information about the mythtv-users mailing list