[mythtv-users] Installation instructions for mythbuntu 16.04.1

James Linder jam at tigger.ws
Sun Dec 18 02:21:08 UTC 2016


 
>>>> Hoi Jay,
>>>> 
>>>> Friday, December 16, 2016, 5:52:40 PM, you wrote:
>>>> 
>>>>> On 12/16/2016 8:20 AM, Hika van den Hoven wrote:
>>>>>> Good job! Jim and Philip! :-)
>>>>>> 
>>>>>> _______________________________________________
>>>>>> mythtv-users mailing list
>>>>>> mythtv-users at mythtv.org
>>>>>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>>>>>> http://wiki.mythtv.org/Mailing_List_etiquette
>>>>>> MythTV Forums: https://forum.mythtv.org
>>>>>> 
>>>>> I'm still running mythbuntu 14.04 LTS, and have no need to upgrade to
>>>>> 16.04 at this time.  There will come a time when I will need to, so I
>>>>> could use some clarification about the changes to systemd.
>>>>> I have several HDHomeRun tuners, so I need to make mythtv-backend wait
>>>>> until they are ready.  However, the proposed changes to wait for the
>>>>> network to be up seem insufficient to me.  It is not the network that
>>>>> mythtv-backend needs to wait for, but the HDHomeRun tuners.  The tuners
>>>>> require an IP address, obtained via DHCP, so it seems that
>>>>> mythtv-backend really needs to wait for the HDHomeRun tuners to get
>>>>> their IP addresses, which is hard to determine, or at least until the
>>>>> DHCP server is running.
>>>>> I remember on my old 0.21 version, I added an HDHomeRun startup script
>>>>> that waited until it could access the HDHomeRun tuners, and changed the
>>>>> mythtv-backend startup order to after that to accomplish the wait.  I
>>>>> have no idea what 14.04 (0.27) is doing here, but moving on to 16.04
>>>>> (0.28, systemd), seems like something more is needed.
>>>>> Jay
>>>>> _______________________________________________
>>>> I have a ping loop in my mythbackend start script:
>>>> 
>>>>          IsAwake=`ping -q -c1 192.168.223.20 | grep received | cut -f4 -d' '`
>>>>          while [ "$IsAwake" == "0" ]; do
>>>>                  einfo "Waiting for the HD homerun to apear"
>>>>                  sleep 1
>>>>                  IsAwake=`ping -q -c1 192.168.223.20 | grep received | cut -f4 -d' '`
>>>>          done
>>>> 
>>>> The einfo is I think Gentoo specific, but you can replace it with echo
>>>> 
>>>> 
>>>> 
>>>> Tot mails,
>>>>    Hika                            mailto:hikavdh at gmail.com
>>>> 
>>>> "Zonder hoop kun je niet leven
>>>> Zonder leven is er geen hoop
>>>> Het eeuwige dilemma
>>>> Zeker als je hoop moet vernietigen om te kunnen overleven!"
>>>> 
>>>> De lerende Mens
>>>> 
>>>> 
>>> Yes, I remember doing something like that in my old HDHomeRun init
>>> script (0.21).  So if this gets added to the mythtvbackend start script
>>> on 16.04, do you need to make any of the mentioned systemd changes?
>>> Jay
>> I don't know if you can use it this way with systemd. Me and systemd
>> do not like each other and I will stay with openrc. Any of the sytemd
>> gurus has to see if this can be added/adapted to the systemd
>> 'startscript'.
>> But anyway this approach will implicitly also wait till the network is
>> fully up as else no ping reply will be received. So the other wait
>> solutions are no longer needed.
> Yes, this is what I was trying to understand better for the systemd 
> startup - it is NOT the network that mythtv-backend needs to wait for, 
> but rather the HDHomeRun tuners, which require more than just the 
> network (i.e., DHCP server, IP addresses).
> 
>> You DO need to give your HD Homerun a static address on your router or
>> it might change over time!
> The MythTV backend is the DHCP server for the HDHomeRuns and does have 
> IP address reservations (static addresses) for them.  I also have host 
> names for them defined in /etc/hosts for convenience.  My HDHomeRun 
> tuners are on a dedicated LAN (separate NIC card).

The other week Stephen Worthington Posted this. I used it in part and it certainly helped me and it addresses the problem you have exactly

--------------------------------------------------------------------

Ok, because you have network tuners and other frontends, that means
that the default systemd file for mythbackend is broken for you, and
you will need to apply a fix.  The HVR-2250, I think, is also a tuner
that has a slow firmware upload, so you will likely need the fix to
make mythbackend wait until the tuners are up before starting.  I have
a similar setup on my test MythTV box, so I will list all the fixes
that I remember doing to make 16.04 work properly for this setup.

1) Create a new set of rules for udev that produce systemd events for
the tuners.  Create a new file in /etc/udev/rules.d.  I have called
mine 99-mythbackend.rules.  Put this in it:

#
# Create systemd device units for capture devices
#
SUBSYSTEM=="video4linux", TAG+="systemd"
SUBSYSTEM=="dvb", TAG+="systemd"
SUBSYSTEM=="firewire", TAG+="systemd"

The file should be "chown root:root" and "chmod a=r,u=rw".

2) Create a new directory /etc/systemd/system/mythtv-backend.service.d
where you put an override file for systemd to override some of the
settings from the package installed file
(/lib/systemd/system/mythtv-backend.service) that controls mythbackend
startup and shutdown.

The new mythtv-backend.service.d directory should be "chown root:root"
and "chmod a=rx,u=rwx".

3) Create a new .conf file in the new mythtv-backend.service.d
directory.  I have called mine mythtv-backend-override.conf.  This is
what I think you will need, presuming that the HVR-2250 creates two
devices on /dev/dvb0 and dev/dvb1:

[Unit]
Wants=dev-dvb-adapter0-frontend0.device
After=dev-dvb-adapter0-frontend0.device
Wants=dev-dvb-adapter1-frontend0.device
After=dev-dvb-adapter1-frontend0.device

After=NetworkManager-wait-online.service

The final After line tells systemd to wait until NetworkManager has
the network fully up and running, instead of just the localhost
interface being up.  That allows mythbackend to find the external IP
address it is configured for, otherwise it will immediately shut down
again.  It also means that mythbackend will be able to talk to the
HDHR tuners, which it does immediately after startup.  If it can not
talk to them then, it will mark them as failed and not try to use them
after that.

The .conf file should be "chown root:root" and "chmod a=r,u=rw".

4) Check if the NetworkManager-wait-online.service is enabled:

systemctl status NetworkManager-wait-online.service

Here is what I get from that command:

root at lith:~# systemctl status NetworkManager-wait-online.service
? NetworkManager-wait-online.service - Network Manager Wait Online
  Loaded: loaded
(/lib/systemd/system/NetworkManager-wait-online.service; enabled;
vendor preset: enabled)
  Active: active (exited) since Sun 2016-11-27 17:34:27 NZDT; 10h ago
    Docs: man:nm-online(1)
 Process: 926 ExecStart=/usr/bin/nm-online -s -q --timeout=30
(code=exited, status=0/SUCCESS)
Main PID: 926 (code=exited, status=0/SUCCESS)
  CGroup: /system.slice/NetworkManager-wait-online.service

Nov 27 17:34:11 lith systemd[1]: Starting Network Manager Wait
Online...
Nov 27 17:34:27 lith systemd[1]: Started Network Manager Wait Online.

See the "enabled" on the third line.  If that is not present, then you
need to enable the service:

systemctl enable NetworkManager-wait-online.service

I believe it is not enabled by default in new 16.04 installs.

5) Optional.  In 16.04, the naming of the Ethernet adapters has
changed to a new scheme.  You can just live with that new scheme, and
use the NetworkManager GUI to put your IP address settings and so on
on the adapter.  But if you have the settings in the
/etc/network/interfaces file, the old 14.04 settings will fail as they
will have the wrong adapter name.  I hate the new names, as I am used
to using eth0, so I always put in config to change the names of my
Ethernet adapters to what I want them to be.  Here is what I have for
my test PC, which has three Ethernet ports at the moment:

# Asus P5K-E motherboard
SUBSYSTEM=="net", ACTION=="add",
ATTR{address}=="00:1f:c6:24:64:ce",KERNEL=="enp2s0", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add",
ATTR{address}=="00:07:e9:11:c5:95",KERNEL=="enp6s2", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add",
ATTR{address}=="00:1b:21:25:13:96",KERNEL=="enp4s0", NAME="eth2"

Note that is three lines - each line is long enough to get wrapped in
emails.

That goes in my /etc/udev/rules.d/20-network.rules file, which is
"chown root:root" and "chmod a=r,u=rw".

You get the names and MAC addresses needed for the above from an
ifconfig command.

After doing all that config on a new 16.04 install or upgrade, you
need to reboot to make it work.

If you hate using UUIDs in your fstab files, these days it is now
possible to label the partitions and replace your UUID= IDs with
LABEL= instead.  Use gparted to label each partition with a unique
name, then change fstab to match.  Here is some of my test PC fstab,
as an example:

#UUID=4cdea8a6-5646-4a7a-8391-a5b1f4ed28c2      /               ext4
errors=remount-ro 0       1
LABEL=Ubuntu16.04-2                             /               ext4
errors=remount-ro 0       1

# swap was on /dev/sdb7 during installation
UUID=e7612859-ea33-4acb-9b70-b674dbc626b2       none            swap
sw              0       0

LABEL=data                                      /mnt/data       ext4
relatime,errors=remount-ro 0    2

LABEL=gt70-rec1                                        /mnt/gt70-rec1
jfs     relatime,errors=remount-ro 0    2
LABEL=gt70-rec2                                        /mnt/gt70-rec2
jfs     relatime,errors=remount-ro 0    2

The long lines will be wrapped by the email.  I have not yet gotten
around to labeling my swap partition, but I think that now even swap
partitions can be identified by label instead of UUID.

Since you do not use SQL, there is no need to change from MySQL to
MariaDB.  I have made that change as the MySQL V5.7 installed by 16.04
now uses the editline library for its command line tools, instead of
readline.  That makes it difficult to pull up and re-use old SQL
commands, instead of having to re-type them completely.

————————————————————————————————
James
 


More information about the mythtv-users mailing list