<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 27, 2020 at 12:16 PM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 27 Jul 2020 10:43:53 -0400, you wrote:<br>
<br>
>I'm doing some planning for moving from MythTV v31 on Ubuntu 18.04 to<br>
>MythTV v31 on Ubuntu 20.04.  There are a lot of considerations, like my<br>
>current system using MariaDB and the current issue regarding that on Ubuntu<br>
>20.04.<br>
><br>
>However, my concerns today are related to udev rules and systemd overrides.<br>
><br>
>On my 18.04 system, I have one udev rule related to mythtv;<br>
>99-mythbackend.rules<br>
><br>
>SUBSYSTEM=="video4linux", TAG+="systemd"<br>
>SUBSYSTEM=="dvb", TAG+="systemd"<br>
>SUBSYSTEM=="firewire", TAG+="systemd"<br>
><br>
>When I installed mythtv v31 on a virtual machine of Ubuntu 20.04, this file<br>
>was not there. I probably created it myself because of the Hauppauge WinTV<br>
>HD Quad PCIe tuner card I was using.<br>
><br>
>So is this still necessary for Ubuntu 20.04 and mythtv v31?<br>
><br>
>Also,  on my current system I have an override file in<br>
>/etc/systemd/system/mythtv-backend.service.d/ythtv-backend-override.conf:<br>
>[Unit]<br>
>Wants=dev-dvb-adapter0-frontend0.device<br>
>After=dev-dvb-adapter0-frontend0.device<br>
>Wants=dev-dvb-adapter1-frontend0.device<br>
>After=dev-dvb-adapter1-frontend0.device<br>
>Wants=dev-dvb-adapter2-frontend0.device<br>
>After=dev-dvb-adapter2-frontend0.device<br>
>Wants=dev-dvb-adapter3-frontend0.device<br>
>After=dev-dvb-adapter3-frontend0.device<br>
><br>
>After=NetworkManager-wait-online.service<br>
><br>
>I figure this is also related to the Hauppauge card and also my HDHomerun<br>
>tuner.<br>
><br>
>Again I think I did this back with mythtv29 and it's stayed through the<br>
>upgrades to v31.<br>
><br>
>Do I need any of this in mythtv v31 on Ubuntu 20.04?<br>
><br>
>On the Ubuntu 20.04 test virtual machine I have only the HDHR tuner and it<br>
>works fine but I have no udev rules or systemd override file.<br>
><br>
>Thoughts?<br>
><br>
>Jim A<br>
<br>
You will have created those udev rules and the override file manually.<br>
<br>
Those udev rules create the .device targets.  The reason for having<br>
those targets is that it is possible for mythbackend to start before<br>
the tuners are created, and having it wait on the device targets<br>
prevents that.  If mythbackend starts before a tuner is working, when<br>
it tests the tuner at startup that tuner will not work and mythbackend<br>
will mark it as failed and not test it again until the next startup of<br>
mythbackend.<br>
<br>
If you only have the one tuner in the 20.04 system, you need to<br>
comment out all the Wants/After lines referring to non-existent<br>
tuners.  Otherwise mythbackend will only start after a very long<br>
timeout waiting for those tuners.<br>
<br></blockquote><div>It was very interesting when I deleted all my backend tuners recently and added them back in on my 18.04 v31 system, I ended up with only one adapter name and when I added all 4 there was only one name repeated 4 times.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If you are using networked tuners such as HDHomeruns, you should have<br>
one of the fixes (such as mine) that prevents mythbackend from<br>
starting before the network us up enough for it to access the<br>
networked tuners.  Waiting for NetworkManager-wait-online.service is<br>
not sufficient to ensure that, and each version of Ubuntu tends to<br>
start up faster than the previous version, so mythbackend is getting<br>
started earlier and earlier.  So if it was working OK without such a<br>
fix in 18.04, it may not in 20.04.  It is best to use something that<br>
pings a networked tuner before it allows mythbackend to be started.<br>
Search this list's archives for "wait-until-pingable.py" to find the<br>
threads for my fix.<br>
<br>
And the speed of the SSD you have the system on also affects the<br>
startup speed.  A new system with a super fast M.2 NVMe SSD and lots<br>
of RAM can cause interesting surprises with how fast things start up.<br><br></blockquote><div>So it sounds like for 20.04, I'll continue to create the udev rules and to be safe put back in the wait-for-ping stuff I had back in the v29 days.</div><div><br></div><div>I also noticed that Hauppauge Linux has added Ubuntu 20.04 to their list on supported O/S's on their PPA (<a href="https://hauppauge.com/pages/support/support_linux.html">https://hauppauge.com/pages/support/support_linux.html</a>)</div><div> </div><div>Jim A<br><br></div></div></div>