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