<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 28, 2016 at 7:55 AM, Paulgir <span dir="ltr"><<a href="mailto:paulgir@gmail.com" target="_blank">paulgir@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, 27 Aug 2016 20:06:18 +1200, Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz" target="_blank">stephen_agent@jsw.gen.nz</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sat, 27 Aug 2016 09:23:26 +1200, you wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The use of systemd in 16.04 is what makes the difference in booting.<br>
Systemd works completely differently from upstart, and allows things<br>
to start better in parallel, rather than having to wait and start in<br>
sequence. But because of that, you can get race conditions if you do<br>
not set up the startup conditions properly. The mythbackend startup<br>
conditions in the package as installed are only OK for systems that do<br>
not have external access to MythTV and which have very standard<br>
tuners. Putting in the right conditions (which is where I hope we<br>
have arrived at now) should allow mythbackend to start at the right<br>
time.<br>
<br>
The reports about mythtv-setup taking ages to get to the new capture<br>
card page are likely what I saw when I first tried 0.28 on 16.04. That<br>
is a problem with the code supporting the new VBox network tuners,<br>
where the code involved takes a very long time to decide that there<br>
are no VBoxes on the network. In my case, that happened because I had<br>
not set up my networking on my new test box at that point, so it was<br>
not working properly. Once I sorted out my network setup, the long<br>
timeout waiting for VBox detection went away, although it still takes<br>
longer than it used to. The reason for the problem was quite visible<br>
in the xterm window that pops up to run mythtv-setup.real - I could<br>
see the messages about VBoxes when I swapped to that window while I<br>
was waiting for mythtv-setup.real to open the new tuner page. VBox<br>
support is new in 0.28 and I think this problem is just a bug, but I<br>
have not checked to see if it has been reported yet.<br>
</blockquote>
<br>
In my case networking was the first thing I setup.I used remmina remote<br>
desktop to work on the PVR,so it is the first task on a new install.Then I<br>
tried HDHR configure GUI and that always worked so networking was<br>
functional.So I'm skeptical whether this applies to my situation.<br>
</blockquote>
<br>
My test box is today once again doing the Vbox search problem in<br>
mythtv-setup. On checking ifconfig, I can see that for some reason I<br>
have not yet diagnosed, it has failed to get a IPv6 address via<br>
DHCPv6, and this seems to be triggering the problem. It has done this<br>
at least twice before, but only when running 16.04, so my guess is<br>
that it is yet another systemd timing problem. So if your network is<br>
working for IPv4, but is IPv6 enabled your 16.04 install is not<br>
working there, then that is a trigger for this Vbox bug. Here is what<br>
my mythtv-setup.log file had for this:<br>
<br>
Aug 27 19:03:48 lith mythtv-setup.real: mythtv-setup[11857]: I<br>
CoreContext recorders/vboxutils.cpp:48 (probeDevices) VBox: Using UPNP<br>
to search for Vboxes (3 secs)<br>
Aug 27 19:04:51 lith mythtv-setup.real: mythtv-setup[11857]: I<br>
CoreContext recorders/vboxutils.cpp:105 (doUPNPSearch) VBox:<br>
GetDeviceDesc() failed for <Unknown><br>
Aug 27 19:05:51 lith mythtv-setup.real: mythtv-setup[11857]: I<br>
CoreContext recorders/vboxutils.cpp:105 (doUPNPSearch) VBox:<br>
GetDeviceDesc() failed for <Unknown><br>
Aug 27 19:05:51 lith mythtv-setup.real: mythtv-setup[11857]: E<br>
CoreContext v4l2util.cpp:53 (Open) V4L2(): Could not open '':<br>
#012#011#011#011eno: No such file or directory (2)<br>
Aug 27 19:05:52 lith mythtv-setup.real: mythtv-setup[11857]: W<br>
CoreContext diseqc.cpp:395 (Load) DiSEqCDevTree: No device tree for<br>
cardid 1<br>
<br>
There are two timeouts or a minute or more happening in the Vbox code.<br>
<br>
Unplugging the Ethernet cable and plugging in again fixes the IPv6<br>
address problem on my test box, and then running mythtv-setup produces<br>
this:<br>
<br>
Aug 27 19:15:10 lith mythtv-setup.real: mythtv-setup[12464]: I<br>
CoreContext recorders/vboxutils.cpp:48 (probeDevices) VBox: Using UPNP<br>
to search for Vboxes (3 secs)<br>
Aug 27 19:15:13 lith mythtv-setup.real: mythtv-setup[12464]: I<br>
CoreContext recorders/vboxutils.cpp:105 (doUPNPSearch) VBox:<br>
GetDeviceDesc() failed for <Unknown><br>
Aug 27 19:15:13 lith mythtv-setup.real: mythtv-setup[12464]: E<br>
CoreContext v4l2util.cpp:53 (Open) V4L2(): Could not open '':<br>
#012#011#011#011eno: No such file or directory (2)<br>
Aug 27 19:15:14 lith mythtv-setup.real: mythtv-setup[12464]: W<br>
CoreContext diseqc.cpp:395 (Load) DiSEqCDevTree: No device tree for<br>
cardid 1<br>
<br>
Similar messages but no long timeouts.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have not heard anything about 16.04 losing its capture card setup<br>
though. That is pretty major and I would have expected to see reports<br>
about it on the mythtv-users mailing list by now, but there has been<br>
nothing.<br>
<br>
Using 14.04.05 and 0.28 should be fine for a while, if you want to do<br>
that, but the kernel will not be updated as I think the 14.04.5 kernel<br>
is the last one from 15.10, which is no longer supported. The 14.04.0<br>
kernel (3.13.x) is still being updated and will be as long as 14.04 is<br>
being supported. You would not be avoiding the VBox problem or the<br>
possible loss of capture card setup if you use 0.28 on 14.04. And as<br>
you are using an SSD, 16.04 is recommended for better support for<br>
that. SSDs do work in 14.04, but you do not get all the latest tweaks<br>
without a 4.x kernel.<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What sort of SSD do you have? In 14.04, there are problems running<br>
the fstrim command or the fstab discard option (one or other of which<br>
is necessary for using an SSD). Only a limited range of SSDs are<br>
supported, so you need to check if yours is supported. This comment<br>
is present in the /etc/cron.weekly/fstrim file in 14.04 and is gone in<br>
16.04:<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The SSD is an Adata SP600 64GB the same as I have had on my desktop PC<br>
for several years.Fstrim has not given any trouble on that.<br>
</blockquote>
This does not appear in the whitelist.When I run sudo fstrim -v / I get:<br>
<br>
myth@myth:~$ sudo fstrim -v /<br>
/: 53121429504 bytes were trimmed<br>
myth@myth:~$ sudo fstrim -v /<br>
/: 0 bytes were trimmed<br>
<br>
This is the script I have in /cron.weekly :<br>
<br>
#!/bin/sh<br>
LOG=/var/log/trim.log<br>
echo "*** $(date -R) ***" >> $LOG<br>
fstrim -v / >> $LOG<br>
</blockquote>
<br>
OK, you must have customised the /etc/cron.weekly/fstrim command. That<br>
looks like a good idea - I have borrowed it. I have also shifted the<br>
fstrim to /etc/cron.daily though - I am pretty sure my SSD gets enough<br>
use to need daily trimming. And the log file (which I have renamed to<br>
fstrim.log) needs rotation, so I created a file<br>
</blockquote>
<br></div></div>
I figured weekly was ok for the myth box.My desktop trims daily.<div><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
/etc/logrotate.d/fstrim:<br>
<br>
/var/log/fstrim.log {<br>
daily<br>
size=1M<br>
rotate 7<br>
notifempty<br>
copytruncate<br>
missingok<br>
}<br>
<br>
However, by using a customised /etc/cron.weekly/fstrim file, you have<br>
bypassed the check for unsupported SSDs. The default<br>
/etc/cron.weekly/fstrim file on 14.04 is this:<br>
<br>
#!/bin/sh<br>
# call fstrim-all to trim all mounted file systems which support it<br>
set -e<br>
<br>
# This only runs on Intel and Samsung SSDs by default, as some SSDs<br>
with faulty<br>
# firmware may encounter data loss problems when running fstrim under<br>
high I/O<br>
# load (e. g. <a href="https://launchpad.net/bugs/1259829" rel="noreferrer" target="_blank">https://launchpad.net/bugs/125<wbr>9829</a>). You can append the<br>
# --no-model-check option here to disable the vendor check and run<br>
fstrim on<br>
# all SSD drives.<br>
exec fstrim-all<br>
<br>
That executes the /sbin/fstrim-all script, which has the checks for<br>
which SSDs are supported or not. Looking at that script, Adata is not<br>
listed as being a safe brand to use TRIM on. The safety of the TRIM<br>
command with older kernels varies from one device to another within a<br>
brand, so I think it would be a good idea for you to check the web and<br>
see if yours is a safe one. If not, then you are running a serious<br>
risk using fstrim - if it happens to run at the same time as there is<br>
heavy I/O traffic on your SSD, you could wind up with a trashed<br>
filesystem. So I would recommend disabling automatic fstrim until you<br>
know it is safe, or have upgraded to 16.04 where the kernels are safe<br>
to use TRIM with as they know what devices are unsafe and have the<br>
necessary fixes for other devices. You can still run fstrim manually,<br>
when you know that there will not be high I/O happening while it is<br>
being run, which probably means shutting down mythbackend.<br>
<br>
The SSD I have for my 14.04 setup is fortunately a Samsung one (850<br>
Pro) and is safe. I did not know that when I bought it though - I<br>
just got lucky.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I now have 14.04 set up completed, so I should be able to backup the<br>
database and use that backup to set up 16.04 should I install it.<br>
Would this be correct?<br>
If this is the case I will have another go at 16.04<br>
</blockquote>
<br>
Yes, you can just use a 14.04 database backup to install on 16.04.<br>
Another option for a 16.04 upgrade is to backup the entire 14.04<br>
system (I use Clonezilla) then do an upgrade in place of both the<br>
system and MythTV using do-release-upgrade or the GUI equivalent.<br>
<br>
______________________________<wbr>_________________<br>
</blockquote></div></div>
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.<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br><br></div><div>Why? You have a working 14.04 system. Leave it be.<br><br></div></div></div></div>