[mythtvnz] New install setup - recording problem

Sun Aug 28 05:37:26 BST 2016

On Sun, Aug 28, 2016 at 7:55 AM, Paulgir <paulgir at gmail.com> wrote:

> 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.
>
>

Why? You have a working 14.04 system. Leave it be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/mythtvnz/attachments/20160828/0d88c103/attachment-0001.html>