<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> Does enabling "Auto-commercial-detection jobs when recording starts" add a<br>
> significant amount of overhead to the system? Right now, I can<br>
> simultaneously record three shows (via HD Prime) onto two physical hard<br>
> drives, while I'm watching a previously recorded show without issue. I'm<br>
> just wondering if the additional commercial detection (3 max) would be too<br>
> much for the system.<br>
<br>
</div></div>Too much of what? Additional disk I/O or CPU to do the decoding and<br>
detection?<br>
<br>
Ideally, your commercial detection processes can keep up with the<br>
writing of the recording to the disk (i.e. real-time) because then you<br>
shouldn't incur additional disk I/O (i.e. to read the stream to be<br>
flagged) on your storage disks since the disk blocks the commflagger<br>
will be wanting to read will already be in the page cache as they got<br>
read from your tuner and written to the storage disk. Assuming your<br>
page cache is big enough (i.e. you have lots of memory left over after<br>
all of your processes grab what they want).<br>
<br>
So, the upshot is that there could be no additional disk I/O but of<br>
course there is additional CPU usage and there needs to be enough CPU<br>
available in order to avoid the additional disk I/O.<br></blockquote><div><br></div><div style>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?</div>
<div style><br></div><div style>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. IIRC, when I record multiple shows on multiple channels back to back, only one of the first shows is comflaged in realtime, Then it does the rest of the shows FIFO, the comflagger may never catch back up. For example:</div>
<div style><br></div><div style> 8 -9 pm </div><div style>Show 1 </div><div style>Show 2</div><div style><br></div><div style>9 - 10 pm</div><div style>Show 3</div><div style>Show 4</div><div style><br></div><div style>
Currently, I thing the comflag jobs would run in order, shows 1, 2, 3, then 4. To reduce IO loads, it would be optimal to run them 1, 3, 2, then 4. Obviously this would require additional logic where multiple comflag threads are allowed. In fact, I believe that if I could sustain multiple realtime threads if I knew it would favor them over on disk recordings... my fear is that enabling multiple threads would thrash my drives when I am recording 3 shows, watching one, and doing 2 comflags; but if I knew that it would prioritize realtime, and that it would use cached data rather than going to disk, there would be far less chance of thrashing.</div>
</div></div></div>