[mythtv-users] Failed to Scan SG Video Hosts

[Tom Lichti]

On Tue, May 15, 2012 at 1:57 PM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 05/15/2012 08:13 AM, Andrew Potter wrote:
>>
>>
>> Ok, Getting this error and with help from Nick Rout, have narrowed it down
>> to an inadvertent hostname change.
>>
>> Hostname was changed when I was having trouble with the install, due to
>> sound issues. So performed a full install again but restored the database. I
>> thought I had kept the same hostname but I screwed  on a capital and
>> transposed a term. I thought the host name was something like
>> Potter-Myth-Master-Backend.
>>
>> I completed a bit more checking and found the storagegroup table has 36
>> rows.
>>
>> 18 where the hostname is incorrect "potter-Myth-Backend-Master" and 18
>> where the hostname is the new name "Potter-Myth-Master-Backend". So as
>> suspected it is a hostname problem.
>>
>>
>> So to fix the issue is it OK to run a sql command to delete all database
>> entries that refer to the old hostname?
>>
>
> The best fix is:
>
> http://www.mythtv.org/wiki/Backend_migration#Retiring_an_old_backend
>
>>
>> Or should I, as suggested in section 23.12 of the documentation, issue the
>> following command:-
>>
>> mythconverg_restore.pl --change_hostname
>> --old_hostname="potter-Myth-Backend-Master"
>> --new_hostname="Potter-Myth-MasterBackend"
>>
>> I am concerned this will just modify the first 18 rows to duplicate the
>> second 18 rows in the storage group table and possibly elsewhere in other
>> tables!!
>>
>
> You can't use the mythconverg_restore.pl --change_hostname approach, now,
> because you've already run MythTV applications with the new host name, so
> you'll end up with (a mess of) duplicate rows.  That will only work if you
> do that /before/ running any applications on the system with the new host
> name--meaning before any applications have put in new data that uses the new
> host name.

I got bitten by this last weekend when I updated to latest master.
There might be an issue in the config.xml/mysql.txt code, and yes, I
knew about the problem, it just didn't seem apparent until it was too
late what the problem was. I upgraded my master/slave backends and
frontends, but for some reason the master backend refuses to read the
config.xml, so even though it had the correct hostname (which was not
FQDN), when it started up it used the FQDN which didn't match the old
hostname, so everything got hosed. In flailing around trying to fix
it, I have done manual updates to the database (yes, I know, bad
kitty, I'm not asking for help, just saying it like it is) but I've
obviously missed some things because I have the issue in this thread
as well. What is interesting is that even if I stop the backend,
update config.xml to the right hostname, and restart the backend, I
still get the 'hostname not found in config, using default'
(paraphrasing, but that's roughly the message), and if I stop the
backend again, it has reverted to 'unique-identifier-goes-here' in the
hostname field. Am I missing something?

Tom