[mythtv-users] Mythbackend segfaulting - Wrong PMT error

Jerry mythtv at hambone.e4ward.com
Thu May 10 23:19:08 UTC 2018


On Thu, May 10, 2018 at 5:05 PM Michael <mythtv at blandford.net> wrote:

> Hello,
>
>
> I have been running mythtv for a creeping up on 15 years!
>
>
> I am currently running on Fedora 28 w/ MythTV from rpmfusion on
> x86_64.    Tuner is an HDHR-3 and I am using US broadcast TV with ~15
> local channels.
>
>
> I have just upgraded from Fedora 27 on May 1st which was the day it came
> out.  Other than normal packages updates, this is the only big change I
> can think of to my system in the recent past.
>
>
> The problem:   As of late last week, I started noticing mythbackend
> segfaulting when tuning some channels.   I am getting errors like:
>
>
> 2018-05-10 13:14:07.848057 E [20407/20681] HDHRStreamHandler
> recorders/dtvsignalmonitor.cpp:361 (HandlePMT) -
> DTVSigMon[5](103CA949-0): Wrong PMT; pmt->pn(4) desired(3)
> 2018-05-10 13:14:07.868227 E [20407/20681] HDHRStreamHandler
> recorders/dtvsignalmonitor.cpp:361 (HandlePMT) -
> DTVSigMon[5](103CA949-0): Wrong PMT; pmt->pn(5) desired(3)
> 2018-05-10 13:14:07.868238 E [20407/20681] HDHRStreamHandler
> recorders/dtvsignalmonitor.cpp:361 (HandlePMT) -
> DTVSigMon[5](103CA949-0): Wrong PMT; pmt->pn(6) desired(3)
> 2018-05-10 13:14:07.888500 C [20407/20407] CoreContext
> signalhandling.cpp:305 (handleSignal) - Received Aborted: Code -6, PID
> 20407, UID 1010, Value 0x00000000
>
> or
>
>
> 018-05-10 11:35:18.165060 E [32382/607] HDHRStreamHandler
> recorders/dtvsignalmonitor.cpp:361 (HandlePMT) -
> DTVSigMon[9](103CA949-0): Wrong PMT; pmt->pn(4) desired(3)
> 2018-05-10 11:35:18.165255 C [32382/32382] CoreContext
> signalhandling.cpp:305 (handleSignal) - Received Aborted: Code -6, PID
> 32382, UID 1010, Value 0x00000000
>
>
> Searching Google hinted that a rescan was necessary if a channel had
> changed.    I have now tried this multiple times and am having no better
> luck.    I have deleted all capture cards, all input sources, and all
> channels to start everything fresh, but after adding it all back,
> multiple channels are still able to generate a segfault.
>
>
>  From the HDhomerun app, I can tune these channels just fine.
>
>
> Any thoughts on where to look or how to debug this issue?
>
>
> Michael
>

Ticket #13263 fixes that issue and #13264 is a similar issue. I attached
the patches to another thread because the server was down that day:
https://lists.gt.net/mythtv/users/617436

If you can apply them to the rpmFusion mythtv source rpm (editing the .spec
file and adding the patches), you can fix the issues yourself.

I used Mock to rebuild them.  It's a little tricky but it's a good skill to
learn in the event of other patches to other applications down the road.

Depending on how fast your machine is, the build might take an hour, or
maybe more than that, or maybe 30 minutes?.  Once you know it's working,
take a break for a while.

Basically, you:

1. make a folder in your home called rpmbuild (just a suggestion).

1.5 edit ~/.rpmmacros to have one line (there may be many more but this
works):

%_topdir %(echo $HOME)/rpmbuild

2. rpm -ivh <mythtv-29.rpm>  Extracts rpm to rpmbuild/<SUBDIRS>

3. edit rpmbuild/mythtv.spec to add patch below
Name/Version/Release/Summary block (right under Source0:  I put Patch0:
patch0.patch  and Patch1:patch1.patch (use better names here))  Increment
the Release by 1 (not the version).

4. in SOURCES directory, add patch0.patch and patch1.patch

4.5. Install mock:  dnf install mock

5. Use this config for mock or modify it to suit you:
https://pastebin.com/Ny2Dp5WL  See the title of the paste for the filename.

6. These steps worked for me with Kodi.  Change <kodi> to <mythtv> where
appropriate.  See:

  https://oglok.github.io/2016-10-05-How-to-build-RPMs-with-Mock/

https://wiki.nikhef.nl/grid/Building_RPMs_using_mock#Generating_the_binary_and_source_RPMs

https://blog.packagecloud.io/eng/2015/05/11/building-rpm-packages-with-mock/

and there are more.

My usual steps, for what it's worth:

  [hambone at localhost rpmbuild]$ mock -r fedora-28-rpmfusion-x86_64
--spec=./SPECS/kodi.spec --sources=./SOURCES/ --buildsrpm
  [hambone at localhost rpmbuild]$ cp
/var/lib/mock/fedora-28-rpmfusion-x86_64/result/kodi-17.6-7.fc28.src.rpm ~
  [hambone at localhost rpmbuild]$ mock -r fedora-28-rpmfusion-x86_64
--rebuild ~/kodi-17.6-7.fc28.src.rpm
  [hambone at localhost rpmbuild]$ mock -r fedora-28-rpmfusion-x86_64 –-clean

7. Everthying gets dumped in that
/var/lib/mock/fedora-28-rpmfusin-x86-64/result directory.  Try them out.
rm *debug*.rpm *devel*.rpm (or save them just in case - I would).  dnf
install ./*.rpm.

8. Drink a beer, do something illegal, take a nap.  That should do it.

I'm sure something official will come down the pike soon.  You can replace
your fix with the official one when you get it.  These patches saved me a
few times already.

Hope that helps,
Jerry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20180510/8e953ab4/attachment.html>


More information about the mythtv-users mailing list