Fail to access DB (but mythweb and backend work!)

[grandmastermarclar]

I can access my DB using mysql -h 192.168.1.234 -u mythtv -pmythtv mythconverg...

(oh, and 192.168.1.234 is the IP of the first interface from ifconfig...)

I can still access mythweb, and it appears from the logs that mythbackend is working correctly.

However, mythfrontend, mythtv-setup, and mythfilldatabase, are all unable to log in to the database. All instances of config.xml on my combined frontend/backend setup have the same DB login credentials, and were working with version 29.

Using MariaDB 10.2, Ubuntu 18.04, mythtv 2:30.0~master.20180426.ba4c52b-0ubuntu0mythbuntu1

No clue in logs (with all debug possible), why it's failing. Could it be some silent fail on a missing library?

[Peter Bennett]

You will get a better response by sending email to the mythtv-users (mythtv-users at mythtv.org) or on the forums (forum.mythtv.org). It sounds like a setup issue and not a bug.

[grandmastermarclar]

Result of mythfrontend --loglevel debug --logpath /tmp/ --verbose all

[grandmastermarclar]

/home/ian/.mythtv/config.xml

[grandmastermarclar]

/etc/mythtv/config.xml (which is symlinked from /home/mythtv/.mythtv/config.xml)

[grandmastermarclar]

Result of ifconfig

[grandmastermarclar]

After amending the IP address in mythtv-setup (from 192.168.1.234 to 192.168.1.234, yes the same), then save and exit, mythtv-setup.log shows:

Jun  3 14:08:08 babylon mythtv-setup.real: mythtv-setup[11636]: I CoreContext mythcontext.cpp:895 (TestDBconnection) Start up testing connections. DB 192.168.1.234, BE , attempt 0, status start
Jun  3 14:08:09 babylon mythtv-setup.real: mythtv-setup[11636]: I CoreContext mythcontext.cpp:895 (TestDBconnection) Start up testing connections. DB 192.168.1.234, BE , attempt 1, status start
Jun  3 14:08:09 babylon mythtv-setup.real: mythtv-setup[11636]: I CoreContext mythmainwindow.cpp:2996 (LockInputDevices) Locking input devices
Jun  3 14:08:09 babylon mythtv-setup.real: mythtv-setup[11636]: N CoreContext mythmainwindow.cpp:3055 (PauseIdleTimer) Suspending idle timer
Jun  3 14:08:11 babylon mythtv-setup.real: mythtv-setup[11636]: E CoreContext mythdbcon.cpp:895 (prepare) Error preparing query: SELECT data FROM settings WHERE value = :KEY AND hostname = :HOSTNAME
Jun  3 14:08:11 babylon mythtv-setup.real: mythtv-setup[11636]: E CoreContext mythdbcon.cpp:897 (prepare) Driver error was [2/2013]:#012QMYSQL3: Unable to prepare statement#012Database error was:#012Lost connection to MySQL server during query
Jun  3 14:08:11 babylon mythtv-setup.real: mythtv-setup[11636]: I CoreContext mythdbcon.cpp:267 (Reconnect) MySQL reconnected successfully

...but on screen it is just trying to wake up the database. Odd, as I can still log in using:

ian@babylon:~$ mysql -u mythtv -pmythtv -h 192.168.1.234 mythconverg

[Peter Bennett]

Your wakeonlan section is restarting your mysql instance.

[grandmastermarclar]

I'm afraid this ticket cannot be closed yet. I've found the problem and it definitely is a problem which seems to have been introduced in the last few days.

Previously, I had a combined FE/BE/DB on my local machine. Instead of using 127.0.0.1 throughout, I was using 192.168.1.234. This was working perfectly fine. Since an update of 29 last Friday, everything mythtv-related apart from the BE and mythweb were dead.

I tried upgrading to 30, hoping that would work. Evidently not. However, changing all references of 192.168.1.234 (in both all instances of config.xml and in the mythconverg.settings table), has resurrected everything except for mythtv-status.

It would definitely therefore appear that there has been a change which has made it to both 29 and 30 which breaks any IP setup which isn't entirely on 127.0.0.1. Now, if this is supposed to be the case for the master/sole BE and anything else which is on that same physical machine, this is a change which I've not seen referred to anywhere.

There was a bug a while back which effectively did exactly the same thing: 127.0.0.1 or you're stuck. I deliberately kept using something which would highlight if this ever became a problem again.

[Peter Bennett]

Please attach a copy of your non-working config.xml.