Changing Database name for MythTV

Has anyone tried messing with using a different name for the mythtv database? Been messing around with it and have hit a problem. I've changed /etc/mythtv/config.xml file needed to point to the correct database name but still receive this in the logs (mythtv's logs the mysql server itself seems to be fine). If i start the process manually all is well and everything works great, however when rebooting and allowing it to progress automatically I get the problem below.

Nov 23 02:45:24 Hades mythbackend[1245]: E CoreContext mythdbcon.cpp:844 (prepare) Error preparing query: SELECT data FROM settings WHERE value = :VALUE AND hostname = :HOSTNAME
Nov 23 02:45:24 Hades mythbackend[1245]: E CoreContext mythdbcon.cpp:846 (prepare) Driver error was [2/1146]:
QMYSQL3: Unable to prepare statement
Database error was:
Table 'mythconverg.settings' doesn't exist
Nov 23 02:45:24 Hades mythbackend[1245]: I CoreContext schemawizard.cpp:107 (Compare) No current database version?
Nov 23 02:45:24 Hades mythbackend[1245]: I CoreContext schemawizard.cpp:111 (Compare) Database appears to be empty/new!

Has anyone seen this problem before or know what settings file defines 'mythconverg' ? Any help would be appreciated. Haven't looked into the source yet but just don't expect mythconverg to be hardcoded, so it must be a config file I am missing somewhere. This is just the backend master (sole master), so isn't under user location, so kind of at a loss.

Anyone know where the config file (this only happens during startup not manually) is stored, that controls this log output fragment ?

if you changed the config to correctly look for a different database name then these values are most likely hard coded. also since you changed the config have you done a restart of mythtv service?

yea sadly, what's weird is everythings fine if I manually start mysql and mythtv-backend, but if it's automatically started just get the same bloody error, not the end of the world really just annoying, as you can imagine, got so close to getting it working but failing at the last hurdle.

dont know then. maybe mythtv is using a different config when you manually start it vs when you have it start automatically

Is MySQL coming up before MythTV? Sorry I don't know anything about MythTV, just curious if the order is correct. This post might be better for their forums (if they have one which I imagine they do).

What you have to do is relink the database with the new name. From what I see here its pointing to a null or empty database. That or you could rebuild under the new name but that takes a long time

Sadly lessaj debian now uses systemd and so already does start after the network and mysql, sadly first thing I looked at :(.

Yea sadly that's not as easy as it sounds, new database name has to actually be written in the code or rather make the source less specific (as it seems to be hardcoded, sadly it's only supposed to be your config.xml file that is included with mythtv-backend that should only need to be changed, sadly though seemed they missed this section).

I could of course change the database name back, (aslong as i change the settings back) or just repoint it to mythtv_db, but thats defeating the purpose (as you are essentially saying this is myconverg) and just wanted to see if it handles a different db name (does for most of it as when it notices its an empty db, it upgrades it (fills it) so seems the only problem really with doing it is the mythconverg.settings thing, that is stopping it from working from boot, weird that it's doing it fine once the system is fully loaded).

But hey seems this isn't the only bug on debian mythtv-backend as seems we have a problem with systemd itself now, fun stuff. New debian is a bit of a mess really stuck half way between init.d and systemd making startup stuff a nightmare if it's the old method (most still use the old method and just pipe it to systemd, so some scripts just don't work).

This was more of an experiment than anything else so no matter more diving to do now (gonna go hunting for this systemd bug now :P).