[mythtv-users] HDHomerun locking and pooling in version 30.0?

[Stephen Worthington]

On Tue, 23 Apr 2019 15:54:08 -0400, you wrote:

>I noticed in the database schema updates going from 29.1 to 30.0 that
>the videodevice column of all HDHOMERUN type entries in the
>capturecard table get renamed to remove the tuner number (-0, -1,
>etc). That is for example, tuners with videodevices of 104FFFFF-0 and
>104FFFFF-1 would both end up with just the id of the HDHR unit itself,
>for example 104FFFF.
>
>I discovered that this was all related to this change...I was little
>surprised there  was nothing mentioned about that in the release notes
>(unless it's there and I'm blind):
>
>https://code.mythtv.org/trac/ticket/13339
>
>I understand conceptually what that describes, but I'm curious as to
>how/if it affects scheduling specifically. For example, currently,
>when I look at upcoming recordings, they're assigned to specific
>capturecard ids. Has that somehow changed? Obviously if tuner locking
>and any sort of tuner availability check is being done in real time
>when recording starts, something must obviously be different. Are they
>still assigned in that manner, but with the capability of changing on
>the fly as needed? Mostly just a curiosity on my part, but I'd like to
>have an idea as to what's going on there.
>
>As far as adding any new HDHR units going forward, I understand that
>you would still need to add the proper number of capturecard entries,
>presumable for example two with the same HDHR id in cases where I
>would have previously added one with <id>-0 and one with <id>-1.
>
>In 29.1 in order to get sequentially id'ed entries in capturecard for
>multi-rec virtual tuners, I had to do the following:
>
>1. Add one capture card entry,
>2. Add it's input connection specifying a Max Records of 2,
>3. Repeat the same process for each tuner on each HRHD unit.
>
>I don't think that used to be the case because (I think) in 0.28 the
>max recordings defaulted to 2. I was also curious as to whether 30.0
>is the same as 29.1 in this respect.
>
>Thanks!
>Tom

I do not use HDHR tuners, but I do use tuners via SAT>IP URLs that
work the same way as the HDHR tuners do now after this change.  When a
tuner is needed for a recording, mythbackend just tries to use the
tuner specified in its settings for that tuner.  If that is a generic
ID for a pool of HDHR tuners (or in my case, a URL for access to a
pool of SAT>IP tuners), mythbackend is relying on the pooling
mechanism (external to mythbackend) to assign a real tuner for it to
use.  If there is a free tuner, the pooling mechanism works and gives
it to mythbackend, which will then use it to record.  If there are no
free tuners in the pool, it is not entirely clear what happens.
Presumably, some sort of error message is passed to mythbackend, and
then it has to decide what to do about that.  Mythbackend does not
have any mechanism to try to use another tuner when a tuner fails, so
I would expect that it would work the same way when a tuner is not
available from the pool.  If so, it will to just sit there taking no
further action until the recording time is over, and mark the
recording as failing during that time.  When the recording time is
complete, the recording will be marked as failed and if there is a
repeat that can be recorded, mythbackend may schedule that, depending
on the settings.  This is not a very helpful way of operating, as if
the recording was failed quickly (say within 5 minutes), I have a
number of channels where there is a +1 channel (the same channel
rebroadcast an hour later) and it would be able to try to record the
programme from the +1 channel.  Unfortunately, for hour long
programmes, the recording does not fail until over an hour after it
starts, and that is too late to start recording the +1 version.

For my SAT>IP tuners, the multirec setting allows for a maximum of 2
multirec tuners.  I presume it works the same way for HDHR tuners. You
can choose to set this to 1 if you want, but leaving it at the default
2 allows mythbackend to re-use the same tuner when it is doing
overlapping back-to-back recordings on the same channel.  That is very
useful.  But for HDHR and my SAT>IP channels, mythbackend has no
mechanism to know that another recording it is starting on another
channel is also on the same multiplex as something it is already
recording.  When it is using physical digital tuners it controls, it
does have that mechanism, as it knows the mplexid it needs for the new
recording and can reuse a physical tuner that is already tuned to that
multiplex.  So for HDHR and SAT>IP, whenever it needs to record a
different channel, it just asks the pool for a new tuner.  If the
pooling mechanism is well written, it will check to see if there is
already a physical tuner that is tuned to the multiplex for that
channel, and will reuse that tuner.  That is what happens with SAT>IP
(it is a requirement in the SAT>IP specification), and I would hope
that the HDHR pooling also works that way.  So if you are recording
from 4 channels, but two of those are on the same multiplex, you will
only be using 3 of the available HDHR or SAT>IP tuners.

A consequence of the pool allowing multiple recordings from the same
tuner is the mythbackend never knows how many spare tuners the pool
has, so it just assumes that there is always a spare one and asks for
a new tuner whenever it needs one.  If there is not a spare tuner,
that recording will fail.  If mythbackend had known that a tuner was
not available, it could have used its scheduler to see if it could
rearrange the schedule for other recordings to free up a tuner for
that one, or scheduled some later recording time for that recording.
Or at least told you that there was a conflict.  But that does not
happen.  With SAT>IP (and I presume how with HDHRs), you can create
more tuners than there are physical tuners, to take advantage of the
mechanism that allows re-use of physical tuners that are already on
the right multiplex.  So if you have 5 physical tuners and there are
only 5 multiplexes, you can have say 10 HDHR or SAT>IP tuners in
MythTV and it can happily use all of them at once as there is no way
to run out of physical tuners.  But the normal situation is that you
have fewer physical tuners than you have multiplexes, and then you
have to make a decision about how many HDHR or SAT>IP tuners you tell
MythTV you have.  If you limit the number of tuners you tell MythTV
about to the number of physical tuners you have, and there is no use
of those tuners outside MythTV, then mythbackend will never request a
tuner when there is not one available.  But it will also potentially
miss the ability to record something that is on the same multiplex as
something else that is already being recorded, and tell you that there
is a conflict when it could have just done the recording.

Ideally, what I would like to see is for there to be a mechanism in
the HDHR and SAT>IP pooling that would allow MythTV to know what
channels are on what multiplexes and adjust its scheduling to allow
for that.  It would also be nice if MythTV could know about other use
of the pooled tuners and adjust for that also, but that is rather more
difficult, as other use of the tuners would then require mythbackend
to reschedule recordings by running its scheduler again, and it might
find that there was now a conflict due to the reduced number of tuners
available.  And instead of you being able to take a look at the
schedule ahead of time and fix any conflicts manually, the conflicts
would occur without warning.