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

Ross Boylan rossboylan at stanfordalumni.org
Sat Jan 25 21:11:14 UTC 2020


The latest fixes/30 code seems to have solved the problem, though it makes
an old one more noticeable.  Thank you Klaas, both for the help in this
thread and for your fixes.

Also I disabled the EIT scan on the one tuner "card" that had it, using
mythtv-setup.  BTW, mythtv-setup shows 2 card inputs, each of which can
tune to a max of 2 channels.
Aside from quieting the log and the network, I'm hoping it might solve some
listing problems I've been having (I get uninformative listings like "This
TV program" and mangled listings with the right title and episode but the
description of a completely different show).  Too early to tell about that.

There have been no "lock no longer held" messages since the upgrade
yesterday.  Initially I upgraded the code and left the EIT scan.  The log
showed lots like this:
2020-01-24 17:38:25.091783 I [28488/28491] TVRecEvent tv_rec.cpp:3682
(TuningFrequency) - TVRec[1]: TuningFrequency
2020-01-24 17:38:25.108039 I [28488/28491] TVRecEvent
recorders/hdhrstreamhandler.cpp:385 (Connect) - HDHRSH[1](10424297): Added
2 devices from 10424297
2020-01-24 17:38:25.126302 I [28488/28491] TVRecEvent
recorders/hdhrstreamhandler.cpp:403 (Connect) - HDHRSH[1](10424297):
Connected to device(10424297-0)
2020-01-24 17:38:25.144811 I [28488/28498] Scheduler scheduler.cpp:2472
(HandleReschedule) - Scheduled 519 items in 0.1 = 0.05 match + 0.00 check +
0.03 place
2020-01-24 17:43:50.076449 I [28488/28498] Scheduler scheduler.cpp:2356
(HandleReschedule) - Reschedule requested for MATCH 0 2 12
2020-01-25T11:00:00Z EITScanner
every 4-5 minutes.  Disabling the EIT scan eliminated those; it also
eliminated the constant traffic with the tuner (mythtv-setup's GUI actually
notes that selecting EIT will produce such traffic).

However, there are lots of messages like this in the logs:
2020-01-25 12:24:33.096385 E [2259/7270] HDHRStreamHandler
mpeg/mpegstreamdata.cpp:336 (AssemblePSIP) - MPEGStream[1](0x7f6aa81a86d8):
Error: AFCOffset(4)+StartOfFieldPointer(204)>184, pes length & current
cannot be queried
2020-01-25 12:24:41.165268 E [2259/7270] HDHRStreamHandler
mpeg/mpegstreamdata.cpp:336 (AssemblePSIP) - MPEGStream[1](0x7f6aa81a86d8):
Error: AFCOffset(4)+StartOfFieldPointer(204)>184, pes length & current
cannot be queried
2020-01-25 12:24:53.271139 E [2259/7270] HDHRStreamHandler
mpeg/mpegstreamdata.cpp:336 (AssemblePSIP) - MPEGStream[1](0x7f6aa81a86d8):
Error: AFCOffset(4)+StartOfFieldPointer(243)>184, pes length & current
cannot be queried
2020-01-25 12:25:37.630291 E [2259/7270] HDHRStreamHandler
mpeg/mpegstreamdata.cpp:336 (AssemblePSIP) - MPEGStream[1](0x7f6aa81a86d8):
Error: AFCOffset(4)+StartOfFieldPointer(235)>184, pes length & current
cannot be queried
2020-01-25 12:25:41.653248 E [2259/7270] HDHRStreamHandler
mpeg/mpegstreamdata.cpp:336 (AssemblePSIP) - MPEGStream[1](0x7f6aa81a86d8):
Error: AFCOffset(4)+StartOfFieldPointer(204)>184, pes length & current
cannot be queried
2020-01-25 12:25:45.695751 E [2259/7270] HDHRStreamHandler
mpeg/mpegstreamdata.cpp:336 (AssemblePSIP) - MPEGStream[1](0x7f6aa81a86d8):
Error: AFCOffset(4)+StartOfFieldPointer(204)>184, pes length & current
cannot be queried
2020-01-25 12:25:49.716185 E [2259/7270] HDHRStreamHandler
mpeg/mpegstreamdata.cpp:336 (AssemblePSIP) - MPEGStream[1](0x7f6aa81a86d8):
Error: AFCOffset(4)+StartOfFieldPointer(204)>184, pes length & current
cannot be queried

These were fairly common before the code changes, though they might be more
common now.  I see them whenever something is recording.  They seem to have
a typical time pattern with a delay of about a minute followed by a delay
of a few seconds between messages.  Since I didn't upgrade all the
myth-related packages (see below), I wonder if there might be a version
mismatch contributing to this.

Details of the upgrade procedure:
Initially running mythtv 30 as packaged for Debian buster/stable by
Christian Marillat and friends (thanks to them) at deb-multimedia.org.
Created a VM in which to do the build.  Debian buster.
Got source from myth's main repo and switched to fixes/30 branch.
Grabbed mythtv-dmo_30.0-dmo4.debian.tar.xz from deb-multimedia repo (these
are the debian patches/build system)
   False start #1: got
mythtv-dmo_30.0+fixes20191217.gita27754ae7f-dmo2.debian.tar.xz.  This is
the bleeding edge sid version.
       It had dependencies that weren't in buster.
   False start #2: unzipped that tar.xz file to the top-level of the git
source tree, mythtv/debian
Unzipped the debian files to mythtv/mythtv/debian.
Edited debian/changelog to give it my own version number.
Built the project in mythtv/mythv
Installed mythtv-backend_30.0-dmo4-rb02_amd64.deb on the main system.
   Had to force the install because it wanted mythtv-common with same
version.
The backend log still showed the same version as before.  Checking
suggested the key code changes
for HDHR had actually gone into the libmyth package, so I installed it and
mythtv-common from the new build.  I'm not sure if these steps were
necessary.

The startup log message now shows a different version (hash for my local
head).

All installed myth packages:
ii  mythgallery            1:30.0-dmo2                      amd64
 Image gallery/slideshow add-on module for MythTV
ii  mythgame               1:30.0-dmo2                      amd64
 Emulator & PC Game frontend module for MythTV
ii  mythmusic              1:30.0-dmo2                      amd64
 Music add-on module for MythTV
ii  mythtv                 30.0-dmo4                        all
 Personal video recorder application (client and server)
ii  mythtv-backend         30.0-dmo4-rb02                   amd64
 Personal video recorder application (server)
ii  mythtv-common          30.0-dmo4-rb02                   all
 Personal video recorder application (common data)
ii  mythtv-database        30.0-dmo4                        all
 Personal video recorder application (database)
ii  mythtv-doc             30.0-dmo4                        all
 Personal video recorder application (documentation)
ii  mythtv-frontend        30.0-dmo4                        amd64
 Personal video recorder application (client)
ii  mythtv-status          1.0.1-1                          all
 Show the status of a MythTV backend
ii  mythtv-transcode       30.0-dmo4                        amd64
 Utilities used for transcoding MythTV tasks
ii  mythweather            1:30.0-dmo2                      amd64
 Weather add-on module for MythTV
ii  mythweb                1:30.0+20191210.git24ae9812-dmo1 all
 Web frontend to control MythTV through a web browser
ii  libmyth-30:amd64         30.0-dmo4-rb02 amd64        Common library
code for MythTV and add-on modules (runtime)
ii  libmythavcodec58:amd64   30.0-dmo4      amd64        libavcodec package
for MythTV
ii  libmythavfilter7:amd64   30.0-dmo4      amd64        libavfilter
package for MythTV
ii  libmythavformat58:amd64  30.0-dmo4      amd64        libavformat
package for MythTV
ii  libmythavutil56:amd64    30.0-dmo4      amd64        libavutil package
for MythTV
ii  libmythes-1.2-0:amd64    2:1.2.4-3      amd64        simple thesaurus
library
ii  libmythpostproc55:amd64  30.0-dmo4      amd64        libpostproc
package for MythTV
ii  libmythswresample3:amd64 30.0-dmo4      amd64        swresample package
for MythTV
ii  libmythswscale5:amd64    30.0-dmo4      amd64        libswscale package
for MythTV
ii  libmythtv-perl           30.0-dmo4      all          Personal video
recorder application (common data)

Ross

On Tue, Jan 21, 2020 at 9:47 AM Ross Boylan <rossboylan at stanfordalumni.org>
wrote:

> 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/20200125/18bb33d6/attachment.htm>


More information about the mythtv-users mailing list