[mythtv-users] Commercial Detection during recording

[Brian J. Murrell]

On 13-03-11 01:47 PM, Joseph Fry wrote:
> 
> I often wondered if that was the case... I suspected it would be but until
> now never heard anyone voice it.  Do you know for certain that it will use
> cached data if it's available?

Well, as certain as I am about what I understand about the VFS.  Have I
ever instrumented the kernel enough to see it happening?  No.  Sometimes
you just have to trust that the sun will come up, because it's supposed
to.  :-)

> If so, I wonder if it wouldn't be worthwhile for a patch to adjust the
> commercial detection job priority to always favor realtime comflagging.

I don't think so.  Even with it at lowest priority, if you don't have
enough CPU for it to get to run real-time, you just don't have enough
CPU in your backend(s), or you have other non-myth stuff running on your
backend(s) that you ought not ot.

> IIRC, when I record multiple shows on multiple channels back to back, only
> one of the first shows is comflaged in realtime,

Then you need to increase the number of parallel jobs you allow the BE
to run.

> Then it does the rest of
> the shows FIFO, the comflagger may never catch back up.

That sounds like you have set a max. of 1 job in parallel.

> For example:
> 
>  8 -9 pm
> Show 1
> Show 2
> 
> 9 - 10 pm
> Show 3
> Show 4
> 
> Currently, I thing the comflag jobs would run in order, shows 1, 2, 3, then
> 4.

Or 2,1,4,3 or 1,2,4,3, etc.

> To reduce IO loads, it would be optimal to run them 1, 3, 2, then 4.

How can you run 3 before it's even started?  To reduce IO loads it would
be optimal to run 1 & 2 at the same time, starting at 8pm and 3 & 4 at
the same time starting at 9pm.

> Obviously this would require additional logic where multiple comflag
> threads are allowed.

Multiple commflag threads are allowed.  See above.

> In fact, I believe that if I could sustain multiple
> realtime threads if I knew it would favor them over on disk recordings...

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130311/704b3356/attachment.sig>