Mailing List Archive

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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 4/24/19, Stephen Worthington <stephen_agent@jsw.gen.nz> wrote:
>
> 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.

Thanks for the reply! Actually prior to 29.1 the default was 2, but in
29.1 it defaults to 1. I found that out when adding a new HDHR and
ended up having to redo it, as I wanted 2.

That's why I was saying how you have to go back and forth adding the
physical tuners as capture cards and creating the inputs for them
changing the max recordings to 2. Otherwise you don't end up with
sequential ids.

Since mythtv is the only thing that uses my tuners, I may never
encounter whatever new fail-over logic there might be. As you
mentioned, I like the over lap of recordings that use the same
multiplex. In older versions I sometimes would miss the very end of
shows for example and that never happens now. Whatever this new
functionality is I hope it doesn't cause any issues with the existing
functionality.

As I said in the original email, this seems like a pretty major change
to be totally missing from the release notes.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, 24 Apr 2019 09:52:35 -0400, you wrote:

>On 4/24/19, Stephen Worthington <stephen_agent@jsw.gen.nz> wrote:
>>
>> 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.
>
>Thanks for the reply! Actually prior to 29.1 the default was 2, but in
>29.1 it defaults to 1. I found that out when adding a new HDHR and
>ended up having to redo it, as I wanted 2.
>
>That's why I was saying how you have to go back and forth adding the
>physical tuners as capture cards and creating the inputs for them
>changing the max recordings to 2. Otherwise you don't end up with
>sequential ids.
>
>Since mythtv is the only thing that uses my tuners, I may never
>encounter whatever new fail-over logic there might be. As you
>mentioned, I like the over lap of recordings that use the same
>multiplex. In older versions I sometimes would miss the very end of
>shows for example and that never happens now. Whatever this new
>functionality is I hope it doesn't cause any issues with the existing
>functionality.

As long as you only set the number of HDHR tuners in MythTV to no more
than the number of physical HDHR tuners you have, and have no other
use of those tuners, there should be no problems at all. Unless one
of the tuners goes faulty. I meet the fail mode every few months when
my pay TV card needs to be refreshed in their set top box and all my
encrypted channels fail to record from the SAT>IP tuners.

>As I said in the original email, this seems like a pretty major change
>to be totally missing from the release notes.

Yes, it is a pretty big change. But given how few developers there
are working on MythTV and how hard they work, I am not surprised that
they could miss getting something into the documentation. That is
rather better than missing something in the code.

>Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org