Hi,
I set up a backend with xubuntu-18.04.3-desktop-amd64. Works fine, local Mythfrontend works fine, records, live tv with my HDHomeRun Connect, ect. I'm trying to set up other frontends. Specifically the Raspberry Pi 3+ with the MPEG encoder license. I am using the latest Raspbian Buster with MythTV Light. Both the PC(backend) and RPi are on version 30. However the RPi keeps getting "Database failed to start." on MythTV Startup Status. I do have the setup options in MythTV Light Database Configuration pointed to the IP address of the backend and port, database name, password are all correct. Any suggestions? Please and thank you.
[Solved] Database failed to start on RPi front end with backend on other hardware
Moderator: Forum Moderators
Re: Database failed to start on RPi front end with backend on other hardware
I usually start by looking in the logs. See if the frontend log explains why the connection is failing.
There are lots of other threads here about this type of thing.
See if the remote host can see the DB on the Maser, e.g. nmap -p 3306 <yourMasterHost>
Find your SQL settings, likely in /etc/mysql/mysql.conf.d/mythtv.cnf. I set bind-address=:: that allows
any IPv4 or IPv6 address to connect (you may choose something more restrictive.)
If that's ok try to login from the command line on the remote host: mysql --host <yourMasterHost> --user mythtv -p mythconverg.
If that fails, the frontend won't connect, so fix that 1st. I may be that remote hosts were never allowed to access the DB.
You may need to use the SQL GRANT command.
If logins fail, check config.xml files even though you said they're OK. diff ~/.mythtv/config.xml ~mythtv/.mythtv/config.xml
There are lots of other threads here about this type of thing.
See if the remote host can see the DB on the Maser, e.g. nmap -p 3306 <yourMasterHost>
Find your SQL settings, likely in /etc/mysql/mysql.conf.d/mythtv.cnf. I set bind-address=:: that allows
any IPv4 or IPv6 address to connect (you may choose something more restrictive.)
If that's ok try to login from the command line on the remote host: mysql --host <yourMasterHost> --user mythtv -p mythconverg.
If that fails, the frontend won't connect, so fix that 1st. I may be that remote hosts were never allowed to access the DB.
You may need to use the SQL GRANT command.
If logins fail, check config.xml files even though you said they're OK. diff ~/.mythtv/config.xml ~mythtv/.mythtv/config.xml
Re: Database failed to start on RPi front end with backend on other hardware
Thank you!
SQL port 3306 was closed. By uncommenting bind-address=:: in /etc/mysql/mysql.conf.d/mythtv.cnf did the trick!
SQL port 3306 was closed. By uncommenting bind-address=:: in /etc/mysql/mysql.conf.d/mythtv.cnf did the trick!
Re: [Solved] Database failed to start on RPi front end with backend on other hardware
Since I was trying so many things before the OP I decided to do a clean install. For anyone with same issue I had to change the IP address in the backend GUI to the local IP address of the pc (instead of 127.0.0.1) and also in the mythtv config.xml from "localhost" to the local IP address.
Re: [Solved] Database failed to start on RPi front end with backend on other hardware
To be clear, config.xml is only used by a given host, never from another host. On the backend, localhost should be
used so that a socket will be used rather than TCP. On remote hosts the IP/hostname is required. Of course if the
DB isn't on the same host as the backend, then it can't be localhost ('cause it isn't.) There have been cases where localhost
wasn't defined in /etc/hosts and the 127.0.0.1 address was used. Having a Private Network address in config.xml on the
backend won't break anything, it's just not as efficient.
used so that a socket will be used rather than TCP. On remote hosts the IP/hostname is required. Of course if the
DB isn't on the same host as the backend, then it can't be localhost ('cause it isn't.) There have been cases where localhost
wasn't defined in /etc/hosts and the 127.0.0.1 address was used. Having a Private Network address in config.xml on the
backend won't break anything, it's just not as efficient.