<br><br><div class="gmail_quote">On 23 June 2010 22:55, Douglas Peale <span dir="ltr"><<a href="mailto:Douglas_Peale@comcast.net">Douglas_Peale@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 06/23/2010 02:33 PM, David Engel wrote:<br>> When SchedMoveHigher is enabled, the<br>
> scheduler moves recordings around one at a time and the first fit<br>
> wins. it does not continue on looking for "better" fits.<br>
<br>
</div>The example I cite is a recording of NCIS on ION. I have 7 copies of ION on my system 1 OTA HD, 3 cable HD, and 3 cable SD. All<br>
three cable SD channels had a priority of -10 the rest were priority 0. There was nothing else scheduled at that time that would<br>
match any of my recording criteria. No conflicts.<br>
<br>
So, you contend that in this situation for the scheduler to choose a SD channel over an HD channel is not a bug?<br>
<div class="im"><br></div></blockquote><div><br>Well David says the scheduler is written to find the first fit not the best fit, so yes, there is no bug in so much as the scheduler has worked as it is designed to work. However, I would agree this isn't exactly desirable behavior, but I also know from my own coding days that "best fit" algorithms can be both complex to write and take a long time to run since often best fit can only be discovered when all possible scenarios have been evaluated and I imagine all possible schedules on a busy MythTV system would be a compute intensive task. However there are ways to mitigate this from clever algorithms to just pikcing the best fit found in x time.<br>
<br>But, yes, to repeat, if as David says the scheduler is written to find the first fit, then what you are seeing is the result of scheduler working as it was designed to work.<br></div></div>