[mythtv-users] Mythbuntu 16.04.1 (0.28) Frontend not visible

[Andrew Potter]

>
>-----Original Message-----
>From: mythtv-users [mailto:mythtv-users-bounces at mythtv.org] On Behalf 
>Of Michael T. Dean
>Sent: Thursday, 10 November 2016 11:26 PM
>To: Discussion about MythTV <mythtv-users at mythtv.org>
>Subject: Re: [mythtv-users] Mythbuntu 16.04.1 (0.28) Frontend not 
>visible
>
>On 11/10/2016 12:01 AM, Andrew Potter wrote:
>>
>> OK I had Mythbuntu 14.04 and wanted to upgrade to Mythbuntu 16.04 LTS.
>>
>> I downloaded the 16.04.1 ISO and installed on a fresh SSD drive. 
>> Keeping the old disk as this is a production system.
>>
>> After the installation I restored the old Database (14.04 database) 
>> tot he new system. I can see in the logs that the database was 
>> upgraded and the settings all look to be correct via myth-setup.
>>
>> But the local frontend does not get to the display screens. I have to 
>> hot alt-f4 and I get the this window is busy dialog do you wan t to 
>> stop it.
>>
>> I have looked at the front end logs but cannot see anything
>>
>> The last log I see is about successfully reading the airplay rsa key.
>>
>> The logs are available here http://pastebin.com/KvnVSX4w
>>
>> I am thinking it is possibly a QT issue, ie not rendering a display 
>> correctly, but I do not know enough to diagnose. Of course I could 
>> also be well off the mark.
>>
>> Any help is greatly appreciated.
>>
>
>You're killing mythfrontend in the middle of the MythMusic database 
>schema upgrade (specifically--at least in the logs provided--during the 
>backup it's making before the upgrade).  If you let it run farther in 
>any previous runs, it may have gotten into the middle of the upgrade, 
>at which killing mythfrontend may have done bad things.  Remember that 
>the backend/mythtv-setup upgrades the TV schema.  All plugin schemas 
>are upgraded by the plugins themselves, which run inside the frontend.
>
>In other words, you need to look at more than the last line in the
>log--2 lines before it said what was happening.
>
>Nov 10 08:48:46 Master-Backend mythfrontend.real: mythfrontend[6935]: E 
>CoreContext dbutil.cpp:604 (DoBackup) Backing up database with script:
>'/usr/share/mythtv/mythconverg_backup.pl'
>
>So, you just need a bit more patience when upgrading versions, because 
>backing up the database takes quite a bit of time, even if the upgrades 
>go quickly (and they don't always).  (And, yes, ideally mythfrontend 
>would tell you what's happening, but until someone completely 
>redesigns/refactors/rewrites our database upgrade code, we don't have 
>access to the (new) UI at the time when we're doing the upgrade, so we 
>can't put up any messages.)
>
>Mike
>
>
>OK,
>
>Tried running the frontend from a terminal session using
>
>frontend -v gui
>
>It seemed to do the same thing but I got the following logs only on the 
>terminal , not in the actual frontend logs.
>
>
>2016-11-12 08:46:59.178493 C  Backed up database to file:
>'/mnt/NAS/Public/mythconverg-1344-20161111213327.sql.gz'
>ICE default IO error handler doing an exit(), pid = 3369, errno = 32
>QWaitCondition: cv destroy failure: Device or resource busy
>QWaitCondition: mutex destroy failure: Device or resource busy 
>andrew at Master-Backend:~$
>
>
>I checked on the net and tried renaming the .ICEauthority file to 
>.ICEauthorityold Then ran
>
>Frontend -v gui again
>It went through the database backup again and then Got the dame thing
>
>??
>
>Andrew
>
>Hi All,
>
>Also posting oin the mythbuntu forum site (https://ubuntuforums.org)  
>and Lester on there suggested I diable mythmusic.
>
>I did that and now all is well. So ther is some issue with the plugin 
>and my system/database.
>
>Andrew

The issue is not with mythmusic.  Mythmusic uses its own database tables,
which are not present unless it has been in use.  When the mythmusic plugin
is installed, and a database schema upgrade happens, the main database
tables get upgraded by mythtv-setup or mythbackend, whichever gets run
first.  But for tables for plugins, they are only upgraded when the plugin
runs the first time after the new schema is installed.  For plugins like
mythmusic that only involve mythfrontend, that means the database upgrade
for its tables will only be run the first time mythfrontend runs after the
schema upgrade.

When a schema upgrade is done, an automatic backup of the database is done
before the schema upgrade, as such upgrades are potentially dangerous and
could cause loss of the database if something bad went wrong.  Normally,
database backups happen from a cron job, and there are different permissions
that apply to cron jobs from when a database backup happens from
mythtv-setup, mythbackend or mythfrontend.  It looks like your regular
database backups work as they have the correct permissions to write to your
NAS.  But database backups from mythfrontend do not have the correct
permissions to access your NAS and fail, so mythfrontend aborts and does not
do the mythmusic schema upgrade.  It may well be that database backups from
mythtv-setup and mythbackend could fail in the same way, as they are also
normally run from a different user with different permissions from cron
jobs.

Uninstalling mythmusic is one way to get around the problem temporarily, but
its tables are still in your database and will still need to be upgraded the
next time mythmusic runs.  So when you reinstall the mythmusic plugin, that
will happen and you will have the same problem again.  What you need to do
is sort out the permissions problem, or move where the default location for
database backups is, so that it is in a location accessible to the users
that run mythtv-setup, mythbackend and mythfrontend.  You can still have
your regular database backups going to the NAS, by altering the cron job to
have a command line parameter specifying where the database backup is to be
stored, and overriding the default database backup location.

Unless your NAS is very fast or your database very small, I would not
recommend backing up directly to the NAS.  Database backups work by first
creating a .sql file that is created using mysqldump on the database.  Then
that file is read back and compressed into a .sql.gz file.  So if you do
your backups directly to a NAS or any network location, they will run very
slowly compared to doing them to a local hard disk.  It is better to adjust
your backup cron job to do the backup to a local hard disk other than the
one the database resides on, then when the backup and compression process is
complete, moving the resulting backup file to the NAS as part of the cron
job.


Stephen,

Let me digest that and then have a look. I will take on board your backup
suggestions with the cron job to move the files.

The backup does seem to complete as the frontend log suggests, or am I
reading the log incorrectly, log at 16:28:45?

Nov 11 16:15:43 Master-Backend mythfrontend.real: mythfrontend[2708]: E
CoreContext dbutil.cpp:604 (DoBackup) Backing up database with script:
'/usr/share/mythtv/mythconverg_backup.pl'
Nov 11 16:15:44 Master-Backend mythfrontend.real: mythfrontend[2708]: I
RAOPDevice bonjourregister.cpp:118 (BonjourCallback) Bonjour: Service
registration complete: name '3a452b366e48 at MythTV on Master-Backend' type
'_raop._tcp.' domain: 'local.'
Nov 11 16:15:44 Master-Backend mythfrontend.real: mythfrontend[2708]: I
AirplayServer bonjourregister.cpp:118 (BonjourCallback) Bonjour: Service
registration complete: name 'MythTV on Master-Backend' type '_airplay._tcp.'
domain: 'local.'
Nov 11 16:28:45 Master-Backend mythfrontend.real: mythfrontend[2708]: C
CoreContext dbutil.cpp:625 (DoBackup) Database Backup complete.