Mailing List Archive

Mythbackend segfaulting - Wrong PMT error
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



_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Mythbackend segfaulting - Wrong PMT error [ In reply to ]
On Thu, May 10, 2018 at 5:05 PM Michael <mythtv@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@localhost rpmbuild]$ mock -r fedora-28-rpmfusion-x86_64
--spec=./SPECS/kodi.spec --sources=./SOURCES/ --buildsrpm
[hambone@localhost rpmbuild]$ cp
/var/lib/mock/fedora-28-rpmfusion-x86_64/result/kodi-17.6-7.fc28.src.rpm ~
[hambone@localhost rpmbuild]$ mock -r fedora-28-rpmfusion-x86_64
--rebuild ~/kodi-17.6-7.fc28.src.rpm
[hambone@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
Re: Mythbackend segfaulting - Wrong PMT error [ In reply to ]
On 05/10/2018 04:19 PM, Jerry wrote:
> On Thu, May 10, 2018 at 5:05 PM Michael <mythtv@blandford.net
> <mailto:mythtv@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.
>
>
> My usual steps, for what it's worth:
>
>   [hambone@localhost rpmbuild]$ mock -r fedora-28-rpmfusion-x86_64
> --spec=./SPECS/kodi.spec --sources=./SOURCES/ --buildsrpm
>   [hambone@localhost rpmbuild]$ cp
> /var/lib/mock/fedora-28-rpmfusion-x86_64/result/kodi-17.6-7.fc28.src.rpm
> ~
>   [hambone@localhost rpmbuild]$ mock -r fedora-28-rpmfusion-x86_64
> --rebuild ~/kodi-17.6-7.fc28.src.rpm
>   [hambone@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.
>


Thanks Jerry,

I appreciate your thorough response.

I will admit I noticed the thread regarding Fedora 28, but in skimming
it, I just saw the issue with start-up of the frontend.

After applying those two patches, I am able to tune all of the channels
again!   Thanks you.

Michael