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

[Stephen Worthington]

On Sat, 12 Nov 2016 13:02:36 +1100, you wrote:

>
>
>-----Original Message-----
>From: mythtv-users [mailto:mythtv-users-bounces at mythtv.org] On Behalf Of
>Andrew Potter
>Sent: Saturday, 12 November 2016 9:36 AM
>To: 'Discussion about MythTV' <mythtv-users at mythtv.org>
>Subject: Re: [mythtv-users] Mythbuntu 16.04.1 (0.28) Frontend not visible
>
>
>
>-----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.