[mythtv-users] Recording Priority = 99 not a trump all?

Douglas Peale Douglas_Peale at comcast.net
Wed Jun 23 21:55:27 UTC 2010


On 06/23/2010 02:33 PM, David Engel wrote:
> On Wed, Jun 23, 2010 at 12:30:27PM -0700, Douglas Peale wrote:
>> Then I did understand the priority scheme correctly, and the priority scheme is broken.
>> By setting all SD versions of channels at a priority of -10, there should have been no circumstances where an SD channel was
>> chosen over an HD channel since all of the SD versions were on tuners with equivalent HD versions.
> 
> No, the priority scheme is not broken.  Your understanding of how the
> scheduler uses it is broken.  When SchedMoveHigher is enabled, the
> scheduler moves recordings around one at a time and the first fit
> wins.  it does not continue on looking for "better" fits.
> Consequently, recordings might get moved to lower priority inputs or
> channels.
> 
> If you want to see how the scheduler arrives at its result, add "-v
> schedule" to your mythbackend command line.  If you don't have any
> off-line slaves, you can perform a dummy schedule by running
> "mythbackend -v schedule --testsched".
> 

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
three cable SD channels had a priority of -10 the rest were priority 0. There was nothing else scheduled at that time that would
match any of my recording criteria. No conflicts.

So, you contend that in this situation for the scheduler to choose a SD channel over an HD channel is not a bug?

>> I have worked around this bug by disabling the SD versions. I don't like this workaround though, because when Comcast plays
>> musical channels again it will be hard to notice that the hidden channels have changed since they are hidden.
> 
> If you never want the SD channels to be used, then you should mark
> them as invisible.  That's what I do.
> 
> David

That is what I just said I have done.


More information about the mythtv-users mailing list