<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, May 10, 2018 at 5:05 PM Michael <<a href="mailto:mythtv@blandford.net">mythtv@blandford.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
<br>
I have been running mythtv for a creeping up on 15 years!<br>
<br>
<br>
I am currently running on Fedora 28 w/ MythTV from rpmfusion on <br>
x86_64. Tuner is an HDHR-3 and I am using US broadcast TV with ~15 <br>
local channels.<br>
<br>
<br>
I have just upgraded from Fedora 27 on May 1st which was the day it came <br>
out. Other than normal packages updates, this is the only big change I <br>
can think of to my system in the recent past.<br>
<br>
<br>
The problem: As of late last week, I started noticing mythbackend <br>
segfaulting when tuning some channels. I am getting errors like:<br>
<br>
<br>
2018-05-10 13:14:07.848057 E [20407/20681] HDHRStreamHandler <br>
recorders/dtvsignalmonitor.cpp:361 (HandlePMT) - <br>
DTVSigMon[5](103CA949-0): Wrong PMT; pmt->pn(4) desired(3)<br>
2018-05-10 13:14:07.868227 E [20407/20681] HDHRStreamHandler <br>
recorders/dtvsignalmonitor.cpp:361 (HandlePMT) - <br>
DTVSigMon[5](103CA949-0): Wrong PMT; pmt->pn(5) desired(3)<br>
2018-05-10 13:14:07.868238 E [20407/20681] HDHRStreamHandler <br>
recorders/dtvsignalmonitor.cpp:361 (HandlePMT) - <br>
DTVSigMon[5](103CA949-0): Wrong PMT; pmt->pn(6) desired(3)<br>
2018-05-10 13:14:07.888500 C [20407/20407] CoreContext <br>
signalhandling.cpp:305 (handleSignal) - Received Aborted: Code -6, PID <br>
20407, UID 1010, Value 0x00000000<br>
<br>
or<br>
<br>
<br>
018-05-10 11:35:18.165060 E [32382/607] HDHRStreamHandler <br>
recorders/dtvsignalmonitor.cpp:361 (HandlePMT) - <br>
DTVSigMon[9](103CA949-0): Wrong PMT; pmt->pn(4) desired(3)<br>
2018-05-10 11:35:18.165255 C [32382/32382] CoreContext <br>
signalhandling.cpp:305 (handleSignal) - Received Aborted: Code -6, PID <br>
32382, UID 1010, Value 0x00000000<br>
<br>
<br>
Searching Google hinted that a rescan was necessary if a channel had <br>
changed. I have now tried this multiple times and am having no better <br>
luck. I have deleted all capture cards, all input sources, and all <br>
channels to start everything fresh, but after adding it all back, <br>
multiple channels are still able to generate a segfault.<br>
<br>
<br>
From the HDhomerun app, I can tune these channels just fine.<br>
<br>
<br>
Any thoughts on where to look or how to debug this issue?<br>
<br>
<br>
Michael<br></blockquote><div><br><div><div>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:
<a href="https://lists.gt.net/mythtv/users/617436">https://lists.gt.net/mythtv/users/617436</a><br><br></div>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.<br><br></div><div>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.<br><br></div><div>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.<br></div><div><br>Basically, you:<br><br></div><div>1. make a folder in your home called rpmbuild (just a suggestion).<br></div><div><br>1.5 edit ~/.rpmmacros to have one line (there may be many more but this works):<br><br>%_topdir %(echo $HOME)/rpmbuild<br><br></div><div>2. rpm -ivh <mythtv-29.rpm> Extracts rpm to rpmbuild/<SUBDIRS><br><br></div><div>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).<br><br></div><div>4. in SOURCES directory, add patch0.patch and patch1.patch<br><br></div><div>4.5. Install mock: dnf install mock<br></div><div><br></div><div>5.
Use this config for mock or modify it to suit you:
<a href="https://pastebin.com/Ny2Dp5WL">https://pastebin.com/Ny2Dp5WL</a> See the title of the paste for the
filename.<br></div><div><br>6. These steps worked for me with Kodi. Change <kodi> to <mythtv> where appropriate. See:<br><br> <a href="https://oglok.github.io/2016-10-05-How-to-build-RPMs-with-Mock/">https://oglok.github.io/2016-10-05-How-to-build-RPMs-with-Mock/</a><br> <a href="https://wiki.nikhef.nl/grid/Building_RPMs_using_mock#Generating_the_binary_and_source_RPMs">https://wiki.nikhef.nl/grid/Building_RPMs_using_mock#Generating_the_binary_and_source_RPMs</a><br> <a href="https://blog.packagecloud.io/eng/2015/05/11/building-rpm-packages-with-mock/">https://blog.packagecloud.io/eng/2015/05/11/building-rpm-packages-with-mock/</a><br></div><div><br>and there are more.<br></div><div><br></div><div>My usual steps, for what it's worth:<br></div><div><br> [hambone@localhost rpmbuild]$ mock -r fedora-28-rpmfusion-x86_64 --spec=./SPECS/kodi.spec --sources=./SOURCES/ --buildsrpm <br> [hambone@localhost rpmbuild]$ cp /var/lib/mock/fedora-28-rpmfusion-x86_64/result/kodi-17.6-7.fc28.src.rpm ~ <br> [hambone@localhost rpmbuild]$ mock -r fedora-28-rpmfusion-x86_64 --rebuild ~/kodi-17.6-7.fc28.src.rpm <br> [hambone@localhost rpmbuild]$ mock -r fedora-28-rpmfusion-x86_64 –-clean <br><br></div><div>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.<br><br></div><div>8. Drink a beer, do something illegal, take a nap. That should do it.<br><br></div><div>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.<br><br></div><div>Hope that helps,<br></div><div>Jerry<br></div> </div></div></div>