[mythtv-users] Many recordings fail and then succeed a second later

[Ross Boylan]

On Mon, Jan 20, 2020 at 10:09 AM Klaas de Waal <klaas.de.waal at gmail.com>
wrote:

>
> It looks to me that all your errors are related to the locking. What you
> perceive as a channel scan could be the EIT in action which tries to scan
> every multiplex in the video source for program guide information. This is
> in your configuration enabled for the first tuner of the two tuners. Your
> configuration looks correct to me.
>
> Please check that you have a recent v30 (v30.1 or v30/fixes) and not the
> original v30. In ticket #13407 there is a bug fixed related to the
> HDHomeRun locking and this fix is in the latest v30/fixes and of course in
> master / pre-v31 but not in the original v30.
>
> If your HDHomeRun is on your in-house network (as opposed to a dedicated
> line to your mythtv backend) then you can verify the correct operation of
> HDHomeRun itself by using e.g. an Android app or a PC app. An intermitted
> failure, e.g. from the power supply, could also cause the lock to be lost
> but this should then also influence the behaviour with the original
> HDHomeRun apps.
>

Thank you for the tip; the fixes do sound relevant to my problems.  My
version of myth says " mythbackend version: fixes/30 [v30.0-4fd4d574c6d]".
The fixes/30 sounds good, but the commit seems to be before at least 2 HDHR
changes in current fixes/30 (as well as most other commits in the branch).
I got myth packaged from deb-multimedia.org; I'm running Debian buster.
There's nothing in buster-backports, though there are more recent versions
for pre-release versions of Debian.

My first crack at doing the backport fell afoul of the build dependencies,
so it's going to take some more work to get something  working.

Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200121/43a34b7d/attachment.htm>