<div dir="ltr">Stephen - <div><br></div><div><br></div><div>Thanks for the script, I was hoping you could help with my problem. I don't use the Mythtv Frontend, but I use LIRC to control my HDPVR.</div><div><br></div><div>I upgraded my original 16.04 system to 18.04 so it would update any databases, then copied everything over to shiny new clean-built 18.04 system. ( <a href="https://pcpartpicker.com/b/Zpw6Mp" target="_blank">https://pcpartpicker.com/b/Zpw6Mp</a> )</div><div><br></div><div>The hd=pvr itself is working - cat /dev/video- > test.ts results ina good file.</div><div><br></div><div>But there's no lirc_zilog to load, and no indication on how to install it. <br></div><div><br></div><div>$ sudo modprobe lirc_zilog<br>modprobe: FATAL: Module lirc_zilog not found in directory /lib/modules/4.18.0-25-generic<br><div><div dir="ltr" class="m_5291286452954119858gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><br></div><div>I found the following message in dmesg:</div><div><br></div><div>[ 5.605079] ir-kbd-i2c 16-0071: IR for HDPVR is known to cause problems during recording, use enable_hdpvr modparam to enable<br></div><div><br></div><div>So I created /etc/modprobe.d/ir_kbd-i2c.conf with the line:</div><div><br></div><div>options ir-kbd-i2c enable_hdpvr</div><div><br></div><div># ls -l /dev/lir*<br>crw-rw---- 1 root video 237, 0 Jul 21 12:54 /dev/lirc0<br>lrwxrwxrwx 1 root root 15 Jul 21 12:18 /dev/lircd -> /run/lirc/lircd<br></div><div><br></div><div>I'm now getting this in dmesg:</div><div><br></div><div>root@gossamer:~# dmesg | grep hdpvr<br>[ 5.192866] hdpvr 1-5:1.0: firmware version 0x1e dated Mar 7 2012 08:25:15<br>[ 6.198966] hdpvr 1-5:1.0: device now attached to video0<br>[ 6.198992] usbcore: registered new interface driver hdpvr<br>root@gossamer:~# dmesg | grep lir<br>[ 6.996176] rc rc0: lirc_dev: driver ir_kbd_i2c registered at minor = 0, scancode receiver, raw IR transmitter<br></div><div><br></div><div><br></div><div>root@gossamer:~# irsend --device=/dev/lircd SEND_ONCE blaster 0_41_KEY_POWER<br><br>hardware does not support sending<br>Error running command: Input/output error<br>root@gossamer:~# irsend --device=/dev/lirc0 SEND_ONCE blaster 0_41_KEY_POWER<br>do_connect: could not connect to socket<br>connect: Connection refused<br>Cannot open socket /dev/lirc0: Connection refused<br></div><div><br></div><div>I'm stuck at this point......</div><div><br></div><div>-- <br>Justin B. Alcorn</div><div>The views expressed are not necessarily my own, much less anyone else's<br>PGP Fingerprint CCEB F776 C3FD 1050 C8DB 532E B8B9 BED7 7764 406C</div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 7, 2018 at 11:38 AM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz" target="_blank">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 7 Oct 2018 08:02:02 -0400, you wrote:<br>
<br>
>Has anybody who has a working Ubuntu 16.04.5 system with mythtv backend <br>
>V29 been brave enough to run do-release-upgrade and see what happens?<br>
><br>
>And No I'm not that brave.<br>
><br>
>Jim A<br>
<br>
Yes, I have just done it and am working through the resulting issues.<br>
<br>
I was running a combined frontend+backend v29 system on 16.04.5, but<br>
without HWE, so it was still on kernel 4.4. The upgrade to 18.04.1<br>
went as normal - no problems in the process. I had a number of /etc<br>
files that were modified and I had to patch my changes into the new<br>
versions (or patch the new bits of the new versions into my old<br>
files), but that happens every upgrade. I use MariaDB, having<br>
switched to that at the 16.04 upgrade. That caused no problems.<br>
<br>
The startup and particularly the shutdown times for 18.04 are faster<br>
than for 16.04 - especially if you are using an SSD system drive which<br>
can support much more parallel activity than rotating rust. The work<br>
done on systemd in 18.04 looks like it has paid off.<br>
<br>
The upgrade process did still take several hours, even though I have a<br>
fast NVMe SSD and a gigabit connection to a nearby Ubuntu repository.<br>
If your MythTV box is busy like mine is, you might like to use my<br>
"gaps" Python program to find a large enough gap in your recording<br>
schedule to do the upgrade. It is available on my web server:<br>
<br>
<a href="http://www.jsw.gen.nz/mythtv/gaps" rel="noreferrer" target="_blank">http://www.jsw.gen.nz/mythtv/gaps</a><br>
<br>
and I think you will also need my fixed version of the Utilities.py<br>
library from the Wiki (put it in the same directory):<br>
<br>
<a href="http://www.jsw.gen.nz/mythtv/Utilities.py" rel="noreferrer" target="_blank">http://www.jsw.gen.nz/mythtv/Utilities.py</a><br>
<br>
The issues I know about:<br>
<br>
1) If you have an old Nvidia card that requires the 304 drivers, do<br>
not do the upgrade as the 304 drivers are not available for 18.04 as<br>
Nvidia has stopped support for them, which made Ubuntu also delete<br>
support for them.<br>
<br>
2) If you are using a frontend on the same box, then you will likely<br>
need lirc to work, and as installed by the 18.04 lirc package, it is<br>
badly broken. See the recent "Remote control issue after Ubuntu<br>
upgrade" and "Blasting to STB,using a MCEUSB" threads here. I have a<br>
script on my web server to fix it so it works:<br>
<br>
<a href="http://www.jsw.gen.nz/mythtv/lirc-ubuntu-18.04-install.sh" rel="noreferrer" target="_blank">http://www.jsw.gen.nz/mythtv/lirc-ubuntu-18.04-install.sh</a><br>
<br>
I have just updated the script for a new problem I discovered today.<br>
On my laptop (which I have also just upgraded from 16.04 to 18.04.1),<br>
I use a USB tuner with a builtin IR receiver. I only start<br>
mythbackend and mythfrontend when I am using the laptop for TV, and<br>
when I am using it for other things, I normally do not plug in the USB<br>
tuner. That caused the new lirc to fill up syslog with error<br>
messages. It turned out that the lirc package now also installs a<br>
systemd unit to run irexec in the background using a default config.<br>
Having irexec running when lirc does not have an IR receiver available<br>
was causing all the spurious error messages. So that background job<br>
needs to be disabled:<br>
<br>
sudo systemctl stop irexec<br>
sudo systemctl disable irexec<br>
<br>
3) The ext4 drivers have been updated, so you will no longer be able<br>
to run fsck of 18.04 ext3 and ext4 partitions from earlier versions. I<br>
have a separate partition I use to boot to do repairs on my main<br>
system partition, including doing a full fsck on all my partitions<br>
after a power failure, and I had to update that to 18.04 as well. You<br>
can still boot from an 18.04 live DVD to do repairs, but older<br>
versions will not work. So make sure you have what you need for<br>
repairs available before you upgrade, just in case. And you will need<br>
a recent version of clonezilla also to properly handle the new ext4<br>
updates, if you want to use it to do an image backup of your system<br>
after upgrading.<br>
<br>
4) The x11vnc VNC server seems to be broken in the new 18.04 version.<br>
It crashes whenever I try to use the menu on the MythTV box over a VNC<br>
connection. I am still working my way through this problem - I may<br>
have to use a different VNC server. The recommendation I found on the<br>
web to switch my display manager to lightdm did not work - I was<br>
already using lightdm as that is the default in Mythbuntu (and Xubuntu<br>
I think).<br>
<br>
5) The new OpenVPN version had one of its server config lines change<br>
syntax, so it failed to run until I fixed that. If you are using an<br>
OpenVPN server, check its log to see if you have a problem like that.<br>
<br>
6) logrotate is now being pedantic about the permissions in the<br>
/etc/logrotate.d directory. The files must be 0644 or 0444 or it<br>
ignores that file. The files ignored are listed in the email sent by<br>
the daily logrotate cron job.<br>
<br>
7) SAMBA/CIFS has been updated to a newer version, which will no<br>
longer connect to older (now insecure) versions of the SMB protocol<br>
unless you add options to override the SMB protocol version. I am<br>
still running an older version of SAMBA on my OS/2 server box, so I<br>
had to add the option ",vers=1.0" to all my mount points in fstab for<br>
that box.<br>
<br>
8) PHP has been updated to version 7.2. On one of my boxes (I forget<br>
which), PHP 7.0 had not been disabled, and that made mythweb and<br>
mythexport not work. I had to manually disable PHP 7.0:<br>
<br>
sudo a2dismod php7.0<br>
<br>
Then I had to do these commands as per several other threads here:<br>
<br>
sudo cp -a /etc/php/7.0/apache2/conf.d/20-mythweb.ini<br>
/etc/php/7.2/apache2/conf.d/20-mythweb.ini<br>
sudo a2enmod php7.2<br>
sudo systemctl restart apache2<br>
<br>
I think that after that I could uninstall the PHP 7.0 packages, but I<br>
have not tried that yet.<br>
<br>
9) The Perl setup has been upgraded, and that made the mythexport Perl<br>
.cfi files fail to find their library files which are in the same<br>
directory as they are. I had to modify all the<br>
/usr/share/mythtv/mythexport/*.cgi files to add a line:<br>
<br>
use lib '.';<br>
<br>
to the use statements at the top of each file.<br>
<br>
10) The Python 2 version has been upgraded, and in doing so a module I<br>
was using in my "mythsgu" Python program that uses the MythTV API was<br>
unable to be found<br>
(backports.shutil_get_terminal_size.get_terminal_size). It must have<br>
been split out into a separate package rather than the one it was in<br>
for 16.04, so I had to find it in its new package and install that:<br>
<br>
apt install python-backports-shutil-get-terminal-size<br>
<br>
11) The problem I have had since I upgraded to 16.04 where the ALSA<br>
output for my SPDIF connection to my DAC keeps getting randomly turned<br>
off 1-3 times a day is still present in 18.04.1. I will have to try<br>
and track down the source of that - it is annoying to be watching a TV<br>
recording and have the sound disappear and have to do an "alsactl<br>
restore" command to get it back again.<br>
<br>
12) anacron seems to be running the daily cron jobs at a different<br>
time - about an hour earlier than it used to. I have changed the<br>
/etc/crontab settings back to the old times, but I will have to wait<br>
until tomorrow to see if that fixes it. The old times were normally a<br>
time when I do not have any recordings happening, or only one<br>
recording. Having the cron jobs run earlier was a problem as the<br>
system could be too busy at the time and have recordings fail due to<br>
the huge overheads on the database when it is checked and backed up by<br>
anacron.<br>
<br>
13) On my main MythTV box, but not on my laptop, I am getting several<br>
messages (from grub, I think) saying "symbol table not found" and<br>
"press any key to continue". They do not cause any problems - the<br>
boot process proceeds normally. But I will need to look at why they<br>
are happening.<br>
<br>
That is all I can remember at the moment - I will update this thread<br>
if I find anything new.<br>
_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
<a href="http://lists.mythtv.org/mailman/listinfo/mythtv-users" rel="noreferrer" target="_blank">http://lists.mythtv.org/mailman/listinfo/mythtv-users</a><br>
<a href="http://wiki.mythtv.org/Mailing_List_etiquette" rel="noreferrer" target="_blank">http://wiki.mythtv.org/Mailing_List_etiquette</a><br>
MythTV Forums: <a href="https://forum.mythtv.org" rel="noreferrer" target="_blank">https://forum.mythtv.org</a><br>
</blockquote></div>