mythconverg_restore fails to restore database

[jmike]

After installing 18.04 and MythTV 0.29 and setting directories and permissions I decided to restore the database before starting MythTV Setup. This is what I got:
$ The mythconverg_restore command with the --verbose --drop database --create database --directory /mnt/NASQNAP/MythTV/DBBackups --filename mythconverg-1317-20190607074805.sql.gz parameters.
Configuring environment:
- username: mike
- HOME: /home/mike
- MYTHCONFDIR: /home/mike/.mythtv

Database Information File specified. Ignoring all command-line arguments

Database Information File: database

The argument you supplied for the database information file is invalid.
If you were trying to specify a backup filename, please use the --directory
and --filename arguments.

ERROR: Invalid database information file, stopped at line 710.

The line "Database Information File specified. Ignoring all command-line arguments" seems to be the key but I have no idea what it means except that any information I supplied was ignored. Evidently the mythconverg_restore command ignored the --directory and --filename arguments I provided, and then complained that I did not use the --directory and --filename arguments.

I can't find any information on the Database Information File. Help!

[blm-ubunet]

./mythconverg_restore.pl --help --help
reveals info about the database information file vs resource file..

The database info file is a way of providing all required cmdline options in a text file as tuples.
So much cleaner & reliable to script than hacking a single cmd line up.

cmd option arguments (tuples) are mean to use "=" separator.. you used a <space> char.
./mythconverg_restore.pl --directory=/path/to/backups/ --filename=backup_file.sql.gz --verbose

And that might have confused the script into thinking you had speced a "DB information" file.

If you're just upgraded then you do not have to do anything except run mythtv-setup BEFORE starting BE etc.
Your DB backup just before upgrade is safe somewhere?

[jmike]

I've been away on other business since my last post.
Using the = separator instead of space, made no difference. I did get the backend running and it appears to be ok except for not having my database; at least I can access the backend through MythWeb.
However, when I start a frontend (all of my frontends are remote) I see a blue screen with a box containing this error message:
Error: MythTV database has newer schema (1350) than expected (1348). Database Host: 192.168.0.252. Database Name: Mythconverg.
When I hit the OK, it exits to the OS but Mythfrontend promptly restarts and puts the message right back. A power cycle is the only way I've found to stop it. Both the frontend and the backend are V30 so it isn't a version mismatch. I haven't found a way to check the database schema yet.

[blm-ubunet]

Your cmd line options are causing the script to treat one of the parameters as a database information file.

The "main" schema update is performed by 'mythtv-setup'
Any plug-in schema changes are handled by them somehow.

BE logs should reveal schema.. start BE from terminal or look at systemd logs.
systemctl status mythbackend.service
journalctl -xe
or similar..

So exit FE & stop the BE service & run mythtv-setup.
It creates a backup** before upgrading..

**- success of this probably depends on storage groups &/or correct permissions etc.

[jmike]

Looking in the backend log I find the following entries:
Nov 27 15:31:39 MythTV-MBE mythbackend: mythbackend[1765]: I CoreContext schemawizard.cpp:120 (Compare) Current MythTV Schema Version (DBSchemaVer): 1348
Nov 29 13:01:38 MythTV-MBE mythbackend: mythbackend[27094]: I CoreContext schemawizard.cpp:120 (Compare) Current MythTV Schema Version (DBSchemaVer): 1350
There has been no further reference to schema version in the backend log so I'm assuming that schema 1350 is still being used, which might explain the new frontend's strange message.
The curious part is that the first reference in the backend log of schema 1350 was at the same time that I attempted to connect the new frontend, the same frontend that complained about seeing schema 1350.
MythTV-setup was not run during this period so nothing done on it could have been the cause.

[blm-ubunet]

Sorry, the schema is not revealed in BE logs under normal operation.
But the protocol version is logged on every startup.

MythTV 'master' is at schema version 1357..
1350 schema was commited Dec20 2018 into MythTV v30 & v31-pre ??
1352 schema was commited Nov 2 2019.

I was under the belief that all schema updates were only performed by mythtv-setup & that this had been the way for some time.
I always run mythtv-setup before restarting BE service after recompiling/installing updates.

https://www.mythtv.org/wiki/Database_Backup_and_Restore
--drop database --create database
These should have been:
--drop_database --create_database
forget about the equals char separator

[jmike]

Since the schema was revealed in my BE log then I assume you are saying my operation is not normal (your Sorry, the schema is not revealed in BE logs under normal operation.)?

Are you saying that since I am running MythTV v30 then 1350 schema is what I should expect?

If that is the case then why does MythTV v30 Frontend V30 fail to run, quoting 1350 as the reason (my Sat Nov 30, 2019 4:28 pm post)?

[blm-ubunet]

I think the schema info only shows in logs when there are warnings/errors.

I would guess that the MBE is running v30 & schema 1350 & the problem frontend is running v29 or a version of v30 that only knows about an earlier schema (1348)..
I think that any matching version protocol frontend can connect to a BE but raises schema warnings if they do not match.

Maybe all your packages are coming from different ppa & therefore do not version match.

[jmike]

Problem solved. I just needed to remember to add the ppa for Mythtv 30 and run "apt update, apt full-upgrade" after downloading the new frontend. The v30 frontend is working like a charm.
Thanks for the help and advice.