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

[Stephen Worthington]

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

>On 4/24/19, Stephen Worthington <stephen_agent at 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