[mythtvnz] New install setup - recording problem

[Stephen Worthington]

On Sat, 27 Aug 2016 09:23:26 +1200, you wrote:

>
>> The use of systemd in 16.04 is what makes the difference in booting.
>> Systemd works completely differently from upstart, and allows things
>> to start better in parallel, rather than having to wait and start in
>> sequence.  But because of that, you can get race conditions if you do
>> not set up the startup conditions properly.  The mythbackend startup
>> conditions in the package as installed are only OK for systems that do
>> not have external access to MythTV and which have very standard
>> tuners.  Putting in the right conditions (which is where I hope we
>> have arrived at now) should allow mythbackend to start at the right
>> time.
>>
>> The reports about mythtv-setup taking ages to get to the new capture
>> card page are likely what I saw when I first tried 0.28 on 16.04. That
>> is a problem with the code supporting the new VBox network tuners,
>> where the code involved takes a very long time to decide that there
>> are no VBoxes on the network.  In my case, that happened because I had
>> not set up my networking on my new test box at that point, so it was
>> not working properly.  Once I sorted out my network setup, the long
>> timeout waiting for VBox detection went away, although it still takes
>> longer than it used to.  The reason for the problem was quite visible
>> in the xterm window that pops up to run mythtv-setup.real - I could
>> see the messages about VBoxes when I swapped to that window while I
>> was waiting for mythtv-setup.real to open the new tuner page. VBox
>> support is new in 0.28 and I think this problem is just a bug, but I
>> have not checked to see if it has been reported yet.
>
>In my case networking was the first thing I setup.I used remmina remote  
>desktop to work on the PVR,so it is the first task on a new install.Then I  
>tried HDHR configure GUI and that always worked so networking was  
>functional.So I'm skeptical whether this applies to my situation.

My test box is today once again doing the Vbox search problem in
mythtv-setup.  On checking ifconfig, I can see that for some reason I
have not yet diagnosed, it has failed to get a IPv6 address via
DHCPv6, and this seems to be triggering the problem.  It has done this
at least twice before, but only when running 16.04, so my guess is
that it is yet another systemd timing problem.  So if your network is
working for IPv4, but is IPv6 enabled your 16.04 install is not
working there, then that is a trigger for this Vbox bug.  Here is what
my mythtv-setup.log file had for this:

Aug 27 19:03:48 lith mythtv-setup.real: mythtv-setup[11857]: I
CoreContext recorders/vboxutils.cpp:48 (probeDevices) VBox: Using UPNP
to search for Vboxes (3 secs)
Aug 27 19:04:51 lith mythtv-setup.real: mythtv-setup[11857]: I
CoreContext recorders/vboxutils.cpp:105 (doUPNPSearch) VBox:
GetDeviceDesc() failed for <Unknown>
Aug 27 19:05:51 lith mythtv-setup.real: mythtv-setup[11857]: I
CoreContext recorders/vboxutils.cpp:105 (doUPNPSearch) VBox:
GetDeviceDesc() failed for <Unknown>
Aug 27 19:05:51 lith mythtv-setup.real: mythtv-setup[11857]: E
CoreContext v4l2util.cpp:53 (Open) V4L2(): Could not open '':
#012#011#011#011eno: No such file or directory (2)
Aug 27 19:05:52 lith mythtv-setup.real: mythtv-setup[11857]: W
CoreContext diseqc.cpp:395 (Load) DiSEqCDevTree: No device tree for
cardid 1

There are two timeouts or a minute or more happening in the Vbox code.

Unplugging the Ethernet cable and plugging in again fixes the IPv6
address problem on my test box, and then running mythtv-setup produces
this:

Aug 27 19:15:10 lith mythtv-setup.real: mythtv-setup[12464]: I
CoreContext recorders/vboxutils.cpp:48 (probeDevices) VBox: Using UPNP
to search for Vboxes (3 secs)
Aug 27 19:15:13 lith mythtv-setup.real: mythtv-setup[12464]: I
CoreContext recorders/vboxutils.cpp:105 (doUPNPSearch) VBox:
GetDeviceDesc() failed for <Unknown>
Aug 27 19:15:13 lith mythtv-setup.real: mythtv-setup[12464]: E
CoreContext v4l2util.cpp:53 (Open) V4L2(): Could not open '':
#012#011#011#011eno: No such file or directory (2)
Aug 27 19:15:14 lith mythtv-setup.real: mythtv-setup[12464]: W
CoreContext diseqc.cpp:395 (Load) DiSEqCDevTree: No device tree for
cardid 1

Similar messages but no long timeouts.

>>
>> I have not heard anything about 16.04 losing its capture card setup
>> though.  That is pretty major and I would have expected to see reports
>> about it on the mythtv-users mailing list by now, but there has been
>> nothing.
>>
>> Using 14.04.05 and 0.28 should be fine for a while, if you want to do
>> that, but the kernel will not be updated as I think the 14.04.5 kernel
>> is the last one from 15.10, which is no longer supported.  The 14.04.0
>> kernel (3.13.x) is still being updated and will be as long as 14.04 is
>> being supported.  You would not be avoiding the VBox problem or the
>> possible loss of capture card setup if you use 0.28 on 14.04.  And as
>> you are using an SSD, 16.04 is recommended for better support for
>> that.  SSDs do work in 14.04, but you do not get all the latest tweaks
>> without a 4.x kernel.
>
>>
>> What sort of SSD do you have?  In 14.04, there are problems running
>> the fstrim command or the fstab discard option (one or other of which
>> is necessary for using an SSD).  Only a limited range of SSDs are
>> supported, so you need to check if yours is supported.  This comment
>> is present in the /etc/cron.weekly/fstrim file in 14.04 and is gone in
>> 16.04:
>
>> The SSD is an Adata SP600 64GB the same as I have had on my desktop PC  
>> for several years.Fstrim has not given any trouble on that.
>This does not appear in the whitelist.When I run sudo fstrim -v / I get:
>
>myth at myth:~$ sudo fstrim -v /
>/: 53121429504 bytes were trimmed
>myth at myth:~$ sudo fstrim -v /
>/: 0 bytes were trimmed
>
>This is the script I have in /cron.weekly :
>
>#!/bin/sh
>LOG=/var/log/trim.log
>echo "*** $(date -R) ***" >> $LOG
>fstrim -v / >> $LOG

OK, you must have customised the /etc/cron.weekly/fstrim command. That
looks like a good idea - I have borrowed it.  I have also shifted the
fstrim to /etc/cron.daily though - I am pretty sure my SSD gets enough
use to need daily trimming.  And the log file (which I have renamed to
fstrim.log) needs rotation, so I created a file
/etc/logrotate.d/fstrim:

/var/log/fstrim.log {
        daily
	size=1M
        rotate 7
        notifempty
        copytruncate
        missingok
}

However, by using a customised /etc/cron.weekly/fstrim file, you have
bypassed the check for unsupported SSDs.  The default
/etc/cron.weekly/fstrim file on 14.04 is this:

#!/bin/sh
# call fstrim-all to trim all mounted file systems which support it
set -e

# This only runs on Intel and Samsung SSDs by default, as some SSDs
with faulty
# firmware may encounter data loss problems when running fstrim under
high I/O
# load (e. g.  https://launchpad.net/bugs/1259829). You can append the
# --no-model-check option here to disable the vendor check and run
fstrim on
# all SSD drives.
exec fstrim-all

That executes the /sbin/fstrim-all script, which has the checks for
which SSDs are supported or not.  Looking at that script, Adata is not
listed as being a safe brand to use TRIM on.  The safety of the TRIM
command with older kernels varies from one device to another within a
brand, so I think it would be a good idea for you to check the web and
see if yours is a safe one.  If not, then you are running a serious
risk using fstrim - if it happens to run at the same time as there is
heavy I/O traffic on your SSD, you could wind up with a trashed
filesystem.  So I would recommend disabling automatic fstrim until you
know it is safe, or have upgraded to 16.04 where the kernels are safe
to use TRIM with as they know what devices are unsafe and have the
necessary fixes for other devices.  You can still run fstrim manually,
when you know that there will not be high I/O happening while it is
being run, which probably means shutting down mythbackend.

The SSD I have for my 14.04 setup is fortunately a Samsung one (850
Pro) and is safe.  I did not know that when I bought it though - I
just got lucky.


>I now have 14.04 set up completed, so I should be able to backup the  
>database and use that backup to set up 16.04 should I install it.
>Would this be correct?
>If this is the case I will have another go at 16.04

Yes, you can just use a 14.04 database backup to install on 16.04.
Another option for a 16.04 upgrade is to backup the entire 14.04
system (I use Clonezilla) then do an upgrade in place of both the
system and MythTV using do-release-upgrade or the GUI equivalent.