mythtv not finding tuners when autostarting

[paulh]

There is nothing to fix in MythTV since it's not it's fault it's a problem with the way your distro has set things up.

[Steve Goodey]

Jerry,

I know it can be a struggle. Unfortunately I think users have to realise that MythTV is not Plug and Play. To get a 100% experience you're probably going to have to get your hands dirty. Mythdora, now gone, Mythbuntu and LinHES try to make it easier but with so much different hardware that could be used it's a difficult task.

There are so few devs working on MythTV and with real life getting in the way it's an uphill battle. At the end of the day it's not life and death. It's only TV!

When I built my Mythbuntu 12.04/MythTV 0.27 I put it in a case with a one line LCD display. To get it working was a real head scratcher with internet searches and a lot of experimentation, but eventually it worked. Come an upgrade to Mythbuntu 16.04 and a change to systemd I had all that work with the display to do again.

Getting the capture cards to work was a new problem. On the old system with an ordinary hard drive the tuners had time to come up before MythTV. Now with an SSD and systemd it was another learning curve. However looking on it as a challenge it's a great feeling when the problems get fixed. And then it's possible to give that knowledge back to other users who are having similar problems. That's how I got my system working, with the help of others.

Steve.

[Glb1945]

Paulh,

Certainly it is possible that mythtv can check to see if the tuners are up before starting?

Steve,

I would have given up on myth -setup if I had not found on the web that the password could not be mythtv but taken from the /etc/mythtv
configure file. To me this is just not user friendly and could and should be fixed. As above I believe that on any system it should be able to check to see if the network and tuners are up before starting mythbackend. In a configure file it is possible to check which system the software is on and use the appropriate commands to check to those issues. This is done all of the time in unix, e.g., see the NCAR graphics program that runs on all types of hardware after running a configure file to determine the hardware and software for a machine. Then the code is modified thru make as needed to run on that machine.

Jerry

[paulh]

Jerry

Sure it could be done, is it worth spending the little amount of developer time available on it. I doubt it, I really think the upstream distros should fix there init system files and then this wouldn't be a problem.

[MikeB2013]

Mike,

When I kill mythbackend and restart it the problem always goes away. What is the best other fix you suggest to delay the startup of mythbackend until the tuners are recognized?

Jerry

If you applied the 20 seconds starting delay, you should see something similar to the following when running
systemd-analyze blame after a reboot

Code: Select all

mike@xubuntu1604:~$ systemd-analyze blame
         20.002s mythtv-backend.service
          8.191s NetworkManager-wait-online.service
          1.409s dev-sda1.device
          1.104s apache2.service
          1.089s mysql.service
           268ms accounts-daemon.service
           227ms apparmor.service
           221ms ModemManager.service
           214ms console-setup.service
           163ms irqbalance.service
           153ms avahi-daemon.service
           151ms grub-common.service
           149ms ondemand.service
           149ms speech-dispatcher.service
           125ms systemd-modules-load.service
           121ms keyboard-setup.service
           120ms gpu-manager.service
           113ms systemd-logind.service
           112ms NetworkManager.service
           105ms kmod-static-nodes.service
           105ms resolvconf.service
           104ms ufw.service
            98ms dev-hugepages.mount
            94ms systemd-journal-flush.service
            94ms networking.service
            88ms upower.service
            84ms dev-mqueue.mount
            82ms snapd.service
            80ms apport.service
            75ms lm-sensors.service
            75ms plymouth-read-write.service
            71ms systemd-udev-trigger.service
            68ms rsyslog.service
            64ms sys-kernel-debug.mount
            61ms snapd.socket
            54ms alsa-restore.service
            52ms thermald.service
            52ms systemd-user-sessions.service
            48ms pppd-dns.service
            45ms systemd-tmpfiles-setup.service
            38ms lightdm.service
            36ms systemd-journald.service
            32ms systemd-update-utmp.service
            30ms systemd-udevd.service
            26ms ssh.service
            26ms polkitd.service
            25ms ntp.service
            25ms systemd-sysctl.service
            19ms dev-disk-by\x2duuid-98fc94ac\x2d710f\x2d4735\x2d9a98\x2d6a45a32580b1.swap
            17ms user@1000.service
            16ms udisks2.service
            15ms hddtemp.service
            15ms sys-fs-fuse-connections.mount
            10ms sys-kernel-config.mount
             9ms systemd-tmpfiles-setup-dev.service
             9ms systemd-remount-fs.service
             5ms systemd-random-seed.service
             3ms rtkit-daemon.service
             3ms rc-local.service
             3ms plymouth-quit-wait.service
             3ms systemd-update-utmp-runlevel.service
             2ms setvtrgb.service

and something like this for systemd-analyze critical-chain

Code: Select all

mike@xubuntu1604:~$ systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @31.104s
└─multi-user.target @31.104s
  └─mythtv-backend.service @11.100s +20.002s
    └─mysql.service @10.010s +1.089s
      └─network-online.target @10.007s
        └─NetworkManager-wait-online.service @1.815s +8.191s
          └─NetworkManager.service @1.689s +112ms
            └─dbus.service @1.625s
              └─basic.target @1.590s
                └─sockets.target @1.586s
                  └─snapd.socket @1.519s +61ms
                    └─sysinit.target @1.515s
                      └─swap.target @1.511s
                        └─dev-disk-by\x2duuid-98fc94ac\x2d710f\x2d4735\x2d9a98\x2d6a45a32580b1.swap @1.488s +19ms
                          └─dev-disk-by\x2duuid-98fc94ac\x2d710f\x2d4735\x2d9a98\x2d6a45a32580b1.device @1.484s

[Glb1945]

Paulh,
Somewhere in the code the password in the /etc/mythtv config file is added. How many lines of code to also insert that password for mythtv in the setup program so a user does not need to go searching the web to find that they must use the password from the config file?
Or if they change the mythtv password in the setup to set that password in /etc/ mythtv?
These should be minor changes and would make a significant change to the ease of use.

I also think it should not be difficult to check in the system files to see if init or systemd is being used and modify the startup accordingly?