[mythtv] Followup question on #6138 (HDHomeRun multirec)

[Bill Cizek]

> Things I noticed during testing:
>
> * A peculiarity with creating then deleting recording rules; see
> <URL:http://www.gossamer-threads.com/lists/mythtv/dev/369476#369476>.
> I've only run with multirec since applying the patch so don't know
> whether the issue exists with unpatched or not.

I haven't noticed this on my system, and I've been running dvb multirec 
for the last year -- I think it would have shown up there also.  Then 
again I could have screwed something up.  If anyone else notices it I'll 
take a closer look.

> * A peculiarity with the scheduler. Let me illustrate:
>
> - OTA channels KPIXDT, KTVUDT, KGODT, and KNTVDT. The last two have SD
> multiplexed channels. All are also available via cable, excluding
> the multiplexed.
>
> LINEUP (*=Not available on cable)
> KPIXDT
> KTVUDT
> KGODT
> KGODT2*
> KNTVDT
> KNTVDT2*
> KNTVDT3*
>
> TUNERS
> 1 HDHomeRun physical tuner 1
> 2 HDHomeRun physical tuner 1
> 3 HDHomeRun physical tuner 2
> 4 HDHomeRun physical tuner 2
> 5 Cable tuner 1
> 6 Cable tuner 2
>
>
> * I schedule simultaneous recordings on KPIXDT and KTVUDT.
>
> 1 KPIXDT
> 2
> 3 KTVUDT
> 4
> 5
> 6
>
>
> * I schedule recordings on KGODT and KNTVDT.
>
> 1 KPIXDT
> 2
> 3 KTVUDT
> 4
> 5 KGODT
> 6 KNTVDT
>
>
> * I schedule recordings on KGODT2 and KNTVDT3. The scheduler should
> reassign KPIXDT and KTVUDT to 5 and 6, like so:
>
> 1 KGODT
> 2 KGODT2
> 3 KNTVDT
> 4 KNTVDT3
> 5 KPIXDT
> 6 KTVUDT
>
>
> Instead, I get the following:
>
> 1 KPIXDT
> 2
> 3 KTVUDT
> 4
> 5 KGODT
> 6 KNTVDT
> KGODT2, KNTVDT3: Conflict warnings; no recordings scheduled
>
>
> I know that the MythTV scheduler uses a one-pass model. I also know,
> from the several threads on -users and -dev recently and from my own
> experience, that there are certain peculiarities with how LiveTV works
> with multirec tuner assignments. I do know, though, that the scheduler
> is in my experience pretty smart about reassigning tuners based on
> whether a recording needs a tuner that's already scheduled for use by
> another. Is the above behavior due to your multirec patch, the
> multirec functionality your patch extends, or the scheduler's existing
> design


I only use OTA so I haven't run into any problems like this. My best 
guess, though, is that this is more scheduler related than multirec 
related, especially if you have one source with the multiplexed channels 
(OTA) and one with only the main channel (Cable). If you have any custom 
card, channel or input priorities that could affect this also.

A quick fix might be to reduce the channel priority for the cable 
versions of channels KGODT and KNTVDT (or for any similarly OTA 
multiplexed channels, or even for the cable input in general).  That way 
they'll record on the HDHR if it's available and cable as a last 
resort.  This assumes you've got a good OTA signal.

The attached patch "089-newpad.fixpreroll.patch" might help also. It 
alters the scheduler to do two passes, the first with softpadding. If 
there are any conflicts, it then does a second pass without softpadding. 
It effectively spreads out the recording schedule among more available 
tuners. Without it, if I have two back-to-back programs on the same 
channel, they'll record on the same tuner and not be padded.  With it, 
the back-to-back programs will record on different virtual tuners on the 
same physical tuner, the result being I get pre and post padding if at 
all possible. I don't know if this would help with your problem, but it 
shouldn't hurt. I've used this patch for nearly two years (even before 
multirec) without any problems.  It is based on work done by Martin in 
this thread: http://www.gossamer-threads.com/lists/mythtv/dev/262447#262447

Cheers,
Bill
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 089-newpad.fixpreroll.patch
URL: <http://mythtv.org/pipermail/mythtv-dev/attachments/20090211/c2586ddf/attachment.asc>