[mythtvnz] New install setup - recording problem

Thu Aug 25 10:02:40 BST 2016

I have now got my 16.04 test box running again, and spent some time
this afternoon looking at the log files.

On Wed, 17 Aug 2016 09:40:37 +1200, you wrote:

>On Tue, 16 Aug 2016 20:23:03 +1200, Stephen Worthington  
><stephen_agent at jsw.gen.nz> wrote:
>
>> On Sun, 14 Aug 2016 10:32:48 +1200, you wrote:
>>
>>> Here's a link to a text file with the log snippets you requested:
>>> https://drive.google.com/open?id=0B5RRWPLTmilhLUFhLTFkN3dEeUU
>>
>> I have finally had a free moment to start looking at the log files,
>> starting with the syslogs, and the thing that right away I can see as
>> a problem is that the hostname of the PC has changed from 12.04 (myth)
>> to 16.04 (mythpc).  That screws up the MythTV database quite badly, as
>> lots of settings are per hostname and many other tables have a
>> hostname field.  When changing the hostname of a PC, you have to
>> follow this procedure:
>
>
>My original install of 16.04 had the same hostname as the 12.04  
>install.This was the one where I restored a DB backup from 12.04 onto  
>16.04.When I discovered that this led to a typo error in the command I  
>used to change the permissions on the storage drive,I did a reinstall of  
>16.04 with a new hostname to avoid that mistake.
>On the new install I did not restore a 12.04 DB backup onto it.So the logs  
>you have seen are from a system with a pristine DB.
>
>
>>
>> https://www.mythtv.org/wiki/Hostname_change#Change_the_hostname_of_a_MythTV_frontend_or_backend
>>
>> and also see this:
>>
>> https://www.mythtv.org/wiki/Backend_migration
>>
>> I am not sure how well the hostname change options on
>> mythconverg_restore.pl work - I have never used them.  If they change
>> all the hostnames in all the tables, everything should work a lot
>> better than before.  I believe the right sequence would be to do a new
>> restore of the 12.04 database to the 16.04 setup, then run the
>> hostname change command, then run mythtv-setup to upgrade the database
>> schema, then start mythbackend and run mythfrontend to upgrade any
>> other plugin database that needed it.
>>
>> I think you said you are just installing 16.04 on a new SSD in the
>> same PC.
>
>That is correct.
>
>  If so, then it might be easier to just do a reinstall of
>> 16.04 keeping the old hostname, and then do an ordinary restore of the
>> database.  Once things are all working again, you could then look at
>> changing the hostname.
>
>As of yesterday ,I somehow killed the 16.04 system's ability to  
>boot,setting up Myth Welcome.I ran boot repair but it did not correct the  
>problem.
>I could probably find the problem and fix it but I have decided to  
>reinstall as that will be much quicker.
>I will use the same hostname as 12.04 ,in case I decide to do a DB restore  
> from 12.04.
>I will probably not do a restore,though as I don't have a huge number of  
>recordings on 12.04 and may just move them to /Videos.
>
>I want to,initially, only install the HDHR tuners to see if I have the  
>same start delay.

The HDHR tuners will need a reasonable start delay as they need to
have networking fully up before they can be used.  This page gives how
to do it:

https://www.mythtv.org/wiki/Systemd_mythbackend_Configuration

in the "Delay starting the backend until network has initialized"
section.  But that information is generic, not specific to Ubuntu
16.04.  What I think you need to do first is to try setting things up
so that you can wait for NetworkManager to say the network is up. Only
if that does not work should pingnetwork.service be needed.  So the
first thing to do is this command to see if the right NetworkMangager
target is enabled in systemd:

systemctl status NetworkManager-wait-online.service

If that does not show that the NetworkManager-wait-online.service is
enabled and working, then enable it:

systemctl enable NetworkManager-wait-online.service

Then mythbackend must be made to wait for that target.  In your
mythtv_backend_override.conf, in the [Unit] section, add a new line:

After=NetworkManager-wait-online.service

>>
>> However, that problem would not affect you if you were just running a
>> new database on 16.04, and I have not checked all the emails to see if
>> the latest tests (for the log files) were done with a clean database,
>
>Yes it was clean.
>
>> or using a restored one.  I may be able to work it out from the logs,
>> but please let me know if you can remember.  If the tests were done
>> with a database with wrong hostnames, there is not much point in
>> looking at the mythbackend logs until that problem is fixed.
>>
>> One other minor thing I can see is that the language locale seems to
>> be en_gb on the 12.04 setup, but en_us on the 16.04 one.  Since en_NZ
>> is a variant of en_gb, lots of things show en_gb when the locale is
>> set to en_NZ, so check the output of the "locale" command on 12.04 to
>> see if it is really set to en_NZ.  If so, 16.04 should be set up the
>> same way.  There can be problems with MythTV themes and other subtle
>> things if the locales do not match between the operating system and
>> the MythTV database.
>
>12.04:
>~$ locale
>LANG=en_NZ.UTF-8
>LANGUAGE=en_NZ:en
>LC_CTYPE="en_NZ.UTF-8"
>LC_NUMERIC="en_NZ.UTF-8"
>LC_TIME="en_NZ.UTF-8"
>LC_COLLATE="en_NZ.UTF-8"
>LC_MONETARY="en_NZ.UTF-8"
>LC_MESSAGES="en_NZ.UTF-8"
>LC_PAPER="en_NZ.UTF-8"
>LC_NAME="en_NZ.UTF-8"
>LC_ADDRESS="en_NZ.UTF-8"
>LC_TELEPHONE="en_NZ.UTF-8"
>LC_MEASUREMENT="en_NZ.UTF-8"
>LC_IDENTIFICATION="en_NZ.UTF-8"
>LC_ALL=
>
>
>>
>> When I have some more time I will look further at the logs.
>>
>> BTW My test PC is down for a few days - my mother's MythTV box power
>> supply fan suddenly became very noisy, so I had to use my spare power
>> supply from the test PC to keep her MythTV going until we can get a
>> new power supply for it.  So I am unable to do any testing with 16.04
>> at the moment.

I think I know why systemd was timing out waiting for the /dev/dvb
devices.  It seems I forgot to tell you about creating an
/etc/udev/rules.d/99-mythbackend.rules file:

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

What that does is to make udev send systemd messages when those
devices are created.  Without it, systemd never received any messages
to tell it the devices were ready, hence the timeout.  I think I must
have created that file a while ago, so when I was working out how to
get systemd to wait for the DVB devices, I completely forgot it was
needed.  I really think that file should be installed automatically by
the MythTV packages.  Like the other files in that directory, it needs
to be chown root:root and chmod u=rw,g=r,o=r.

With those changes, systemd should be able to bring up mythbackend
only after both the HVR-2200 and HDHR tuners are available.

From the logs, I am pretty sure that the second firmware file for the
HVR-2200 tuners (dvb-fe-tda10048-1.0.fw) is only loaded after
mythbackend sends them a tuning command for the first time, so there
is no need to wait for that firmware to be loaded.  Doing the firmware
load means that the first tuning of the HVR-2200 tuners will likely
take a bit longer - it is possible that mythbackend may timeout
waiting for a response from the tuner and that may be why it seems to
try those tuners several times as it starts up:

Aug 14 10:09:53 mythpc mythbackend: mythbackend[3168]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms
Aug 14 10:09:58 mythpc mythbackend: mythbackend[3168]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms
Aug 14 10:09:59 mythpc mythbackend: mythbackend[3168]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms
Aug 14 10:10:00 mythpc mythbackend: mythbackend[3168]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms
Aug 14 10:10:02 mythpc mythbackend: mythbackend[3168]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms
Aug 14 10:10:03 mythpc mythbackend: mythbackend[3168]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms

That looks a bit worrying compared to what I see with my /dev/dvb
tuners, where each tuner gets tuned only once, in tuner number order.
But if the tuners are working afterward, that is all that matters.