[mythtv] Loss of "This server is the Master Backend" configuration in fixes/32

[John Pilkington]

On 06/02/2022 14:32, Stephen Worthington wrote:
> On Sun, 6 Feb 2022 14:43:35 +0100, you wrote:
> 
>> On Sun, 6 Feb 2022 at 12:36, John Pilkington <johnpilk222 at gmail.com> wrote:
>>
>>> On 06/02/2022 10:40, Klaas de Waal wrote:
>>>> Hi,
>>>>
>>>> I have now on two different systems that the checkbox for "This server
>>>> is the Master Backend" is unexpectedly unchecked. This is with testing
>>>> the fixes/32. It could just be that I did something wrong but if others
>>>> also experience this issue it might be a bug.
>>>>
>>>> Klaas.
>>>
>>> I have mythtv-setup problems too, but thought they were caused by
>>> unwanted interaction between boxes intended to be independent.  At
>>> present I have switched off the problem box and am wondering if I need a
>>> DB restore.    I dislike the full-screen arrogance of the default setup,
>>> and that it finds several servers with no obvious way of knowing which
>>> is which.   Fortunately, once set up, it usually works.  And I know I'm
>>> supposed to use the 'ten foot interface' model with a single syatem...
>>>
>>> My problems did start after trying to test an updated Dutch translation on
>> my laptop.
>> It looks like starting mythfrontend with the -p command line option, as
>> recommended in the Wiki page
>> https://www.mythtv.org/wiki/Translation#Do_the_translation, is what causes
>> the problems.
>> I did expect the "mythfrontend -p" to ask for the language; instead it
>> comes up with a backend selection page.
>> There are two backends shown with completely identical descriptions.
>> Selecting the first one gives a popup box with a prompt for a PIN code.
>> Entering 0000 fails, the box remains.
>> Selecting the second one works OK without a PIN code. This happens to be
>> the production backend in my attic and this is not what I wanted so I just
>> exited after clicking around for a while.
>> Now on BOTH systems, my laptop and the one in the attic, the "This server
>> is the Master Backend" is unchecked.
>> I have been able to reproduce this once but not twice.
>>
>> Looks like there are the following issues:
>>
>> - The "mythfrontend -p" command is expected to ask for country and language
>> but instead it does something completely different. It could be that the
>> documentation in https://www.mythtv.org/wiki/Translation#Do_the_translation
>> is not correct.
>> - The backend configuration is clobbered by "mythfrontend -p". This should
>> never happen and is the most serious issue.
>> - I can NOT start mythfrontend when I select the backend via the backend
>> selection page; it then asks for a PIN code which is not accepted.  I can
>> however just start mythfrontend without the "-p" option and then it starts
>> OK. This is inconsistent.
>> - The two backends presented in the backend selection page have a 100%
>> identical description. This makes selecting the correct backend a lottery.
> 
> If you copy /usr/share/mythtv/devicemaster.xml to
> /home/mythtv/.mythtv/devicemaster.xml and edit it there, that should
> allow you to change the names that show up when selecting backends.
> 
>> I also think that the default for mythtv-setup should be to appear in a
>> window and not full screen. Typical use for mythtv-setup, at least for me,
>> to run it via ssh on a computer screen and not on the TV. The annoying
>> thing is that this can only be changed in mythfrontend.
> 
> I believe that it is possible to use -O to override settings that are
> in the settings table if the program does not have a native way of
> changing them.  So something like this might work:
> 
> -O RunFrontendInWindow=1
> 
>> Klaas.

Thanks, Stephen, for your suggestions.  So far I haven't seen any 
response to my editing of devicemaster.xml, but I did notice that one 
box is showing 32.202201... and another 33.202202...  Perhaps it needs a 
reboot to be effective.  I had restarted the backend.

Starting mythtv-setup with the -w option made things more bearable, but 
it still wanted to go through the whole setup process again.  So I tried 
drop-and-restore using the most recent backup.

{{{

[john at HPFed mythtv]$ perl mythconverg_restore.pl --drop_database 
--create_database --filename 
/home/john/SGs/MythDBbak/mythconverg-1375-20220203225742.sql.gz
DBD::mysql::st execute failed: Column count of mysql.proc is wrong. 
Expected 21, found 20. Created with MariaDB 100015, now running 100513. 
Please use mariadb-upgrade to fix this error at mythconverg_restore.pl 
line 1052.

ERROR: Unable to drop database.

Fortunately I had "one I made earlier"

[john at HPFed mythtv]$ perl mythconverg_restore.pl --drop_database 
--create_database --filename 
/home/john/SGs/MythDBbak/mythconverg-1375-20220202181807.sql.gz

Successfully restored backup.
[john at HPFed mythtv]$

}}}

This is very similar to what I saw after the DB update failures of a few 
days ago, before the key-length commit, but then the partially-upgraded 
backup was quite small.  Both those above are 28 MB, and 100 MB on the 
el7 box.

John