[mythtvnz] New install setup - recording problem

[Paulgir]

On Sat, 27 Aug 2016 20:06:18 +1200, Stephen Worthington  
<stephen_agent at jsw.gen.nz> wrote:

> 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

I figured weekly was ok for the myth box.My desktop trims daily.


> /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.
>
> _______________________________________________
I already have an image of the 14.04 partition and have a DB backup of the  
freshly setup system.I will start another install of 16.04.1 today.Set up  
the various changes: (vino,firmware,fstab,trim etc) and then restore the  
14.04 DB and start looking at the systemd fixes.