[mythtv-users] mythconverg hygiene question

[Michael T. Dean]

On 07/16/2018 11:03 AM, Don Brett wrote:
> I have a mythconverg database that's been migrated from several 
> versions.  It works fine, but on my latest migration, I notice some 
> lingering hostnames from years ago.  For example, the settings table 
> should have hostname as nick, but it also has andy, kate, katie, null, 
> and localhost (all are earlier boxes).

Null is actually not a earlier-box's hostname--it's a marker for a 
global setting, and needs to be there for those settings that are global.

>   I also see cases of multiple entries of the same property, here are 
> some examples (from settings table):
>
> | AC3PassThru                  | 0 | andy      |
> | AC3PassThru                  | 0 | andy      |
> | AC3PassThru                  | 0 | kate      |
> | AC3PassThru                  | 0 | localhost |
> | AC3PassThru                  | 0 | nick      |
>
> | AdjustFill                        | 0 | andy      |
> | AdjustFill                        | 0 | andy      |
> | AdjustFill                        | 0 | andy      |
> | AdjustFill                        | 0 | kate      |
> | AdjustFill                        | 0 | localhost |
> | AdjustFill                        | 0 | nick      |
>
>
> On each migration, I installed a separate box, copied everything over, 
> then changed the hostname.  Just to add a little detail:
>
> Install database process is:
> drop default database on new box, install blank from script (mc.sql), 
> restore current with mythconverg_restore.pl.
>
> Change hostname command is:
> $ sudo /usr/share/mythtv/mythconverg_restore.pl --change_hostname 
> --old_hostname="nick" --new_hostname="andy"
>

I'm not sure how the duplicate entries would have been created. It's 
possible they're not truly duplicates--that there are some character(s) 
that don't show in the output but that make them different (possibly 
from way back on the MySQL UTF-8-in-utf8-columns transition?).  
Generally, if you try to change a host name to one that already exists, 
the restore script should provide an error to let you know that the host 
name is already in use--at which point (due to an error and unknown 
database state) you should restore the backup again and either use the 
already-existing host name with the settings already there or change 
to/use a different host name for --change_hostname.  It's possible that 
the --change_hostname will run through settings and error later due to 
unique keys in other tables, and perhaps this happened and you didn't 
notice the error/didn't re-restore the database and ended up using a 
partially-changed hostname (losing some settings that you later fixed or 
are just using defaults).

It would make a lot of sense to add a quick check after the argument 
checks in do_hostname_change() that selects all distinct host names from 
settings and, if any match new_hostname, error without even attempting 
to do any host name changes.  With this approach, the script fails fast 
to catch the issue for most cases where it may exist and prevents any 
database changes in case people fail to see the error/fail to respond 
correctly after the error (i.e. by restoring the known-good database 
again and not attempting to change to an already-existing hostname).

>
> Mythconverg_restore.pl does a pretty good job of changing hostnames 
> (loops through all tables), but I don't see a way resolve duplicates.  
> Should I be concerned?

We don't have a way to clean up old host profiles, primarily because 
they could become useful again (if you decide to set up another host and 
want to use the settings you've already customized) and because they 
take up almost no space in the database (just a few kilobytes on disk 
and "none" in memory (for varying values of none, due to MySQL 
potentially having some in its memory at some times--but definitely none 
in MythTV's memory)).  Eventually I hope to make a profile selector tool 
that also allows you to change the profile name (and separates it from 
the host name) as well as copy/delete/create new/export/import profiles.

While you could try pruning some of the values from settings, there are 
many other locations where host-specific settings exist, so you'd be 
leaving parts of the profile around. The values in the database 
(settings and other tables) aren't going to cause a problem, so it's 
probably not worth the effort/risk.  The worst that could happen if you 
leave them is you may choose to re-use a host name that has 
previously-set settings and it may have some values set that don't work 
well with the new host (but even defaults don't always work well with 
all hosts, thus the reason for their being settings).

Mike