[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