[mythtv-users] MythSocket errors, backend unresponsive

[R. G. Newbury]

On 08/07/2010 03:58 PM, Khanh Tran wrote:
> On Fri, Aug 6, 2010 at 5:35 PM, R. G. Newbury<newbury at mandamus.org>  wrote:
>
>>
>> Use mythtv-setup ->  general to ensure that the box is talking to the
>> correct place, then take a look at the mysql settings table, and in
>> particular look out for duplicate instances of a 'value' field and that the
>> hostname field is correct. You should also check any mysql.txt or config.xml
>> files for the correct address.. and finally, check that mysql 'likes' you,
>> by using the user at domain authentication for the mysql console or check the
>> /var/lib/mysql/mysql/user table entries for host,user and password fields.
>> phpMyAdmin is great for this if you are not comfortable using the mysql
>> console and SQL commands.
>>
>>
>>
> can you specify the  relevant tables and fields?  I took a look and couldn't
> find any duplicates or problems with the IP addresses.  Also, do you mean
> mythtv at localhost for the domain?  I don't think I have a domain set up:
>
> mythtv at tv:/mnt>  mysql -u mythtv at localhost -p
> Enter password:
> ERROR 1045 (28000): Access denied for user 'mythtv at localhost'@'localhost'
> (using password: YES)

Using mysql on the local machine IS a special case. Mysql adds the 
'@localhost' if your mysql.txt or config.xml files tell *this* machine 
that the server is on *this* machine. Different things happen if you use 
a machine name or IP in the config.xml file pointing to somewhere else.
Note the comments in the mythtv documentation at section 6.2

Note that if you purposely try 'mysql -u mythVT -p' you will get the 
same error including the '@localhost' wording (except for the 'VT' of 
course).
You got mythsocket errors which means a mysql communication problem.

Your slave mysql client machines must point to the master mysql machine. 
Remember that your mysql server could be a different box from what you 
consider your 'backend' machine although generally there is no 
difference in mythtv-land.

To check who is allowed access, at the master mysql console:
 > use mysql;    # changes to mysql's master control database from 
mythconverg

 > select host,user,password from user;   #Yes! there is a field called 
user, in a table called user!!
+-------------------+--------+------------------+
| host              | user   | password         |
+-------------------+--------+------------------+
| localhost         | root   | 1b3ab4920bfa6d2a |
| tor6.mandamus.org | root   | 1b3ab4920bfa6d2a |
| 192.168.1.81      | root   | 1b3ab4920bfa6d2a |
| localhost         | mythtv | 0476fc026afffe24 |
| tor6.mandamus.org | mythtv | 0476fc026afffe24 |
| 192.168.1.81      | mythtv | 0476fc026afffe24 |
+-------------------+--------+------------------+

I have too many effectively duplicate entries here! (This is my laptop). 
Mainly for testing/learning. You (and Bob Cottingham) will/should have 
entries for each host slave machine as well. Those could have different 
users and passwords. In fact, maybe they SHOULD have different users: 
wonder if the 'going-away' problem is that the mysql server is keeping 
track of users, but not 'users+hosts' in this circumstance? Note that 
this is how the master mysql server sees who is authorized to access the 
server: if I wanted to access my mythbox from this laptop, the mythbox 
mysql server would have to have a 'tor6.mandamus.org' line (plus user + 
password) or all my attempts at access to that box from this box would 
be rejected.

Again, I wonder if that might not be the problem? So check that each 
slave's mysql.txt is pointing to the correct DbHostname (name or IP) and 
that each config.xml has the correct stanza:
       <DefaultBackend>
         <DBHostName>localhost</DBHostName>
         <DBUserName>mythtv</DBUserName>
         <DBPassword>mythtv</DBPassword>
         <DBName>mythconverg</DBName>
         <DBPort>0</DBPort>
       </DefaultBackend>

Note that /home/thisuser/mysql.txt is for this user, on this machine to 
be able to find the mysql server. Note that there is a line for 
localhostname (since it CAN differ from what hostname returns (yes! 
Asking for trouble...but some boxes get set up without a 'hosts' file).
The config.xml file is a myth file.

Way outside the screen we are looking at: do your slave machines NFS 
mount a directory on the master? Check that your slave's NFS mount 
includes 'actime0=0' along with the 'hard,nfsvers=3' and other mount 
options. You may have multiple slaves mounting the same point...but 
(improperly) caching data..


Consider changing the user on each slave/frontend to distinctly identify 
the 'incoming caller' to the mysql server.

This is just the mysql side of things and has nothing to do with the 
master backend/slave backend recording + tuner relationship within Myth. 
But the mysql setup HAS to be correct for Myth to work.

I've never dealt with a slave backend nor for that matter with multiple 
frontends. I have only just played with access to a mysql server from a 
different box (ie access the desktop mysql server from the laptop), and 
once for a short time, played with using the laptop as a frontend to the 
desktop. (Of COURSE I have a full myth setup on my office desktop, AND 
the laptop. For "testing" purposes. That's my story and I'm sticking to 
it. Besides, I don't MESS with the mythbox. Messing with the WAF is 
definitely contra-indicated.)

There are, however, places in the myth setup which affect how myth boxen 
talk to the backend. These are all in the mysql tables.

Main databaes and tables to worry about:
user table in the mysql database, as noted above and
settings table in the mythconverg database.

The settings table of the master mythconverg database holds all the 
individual settings. At the console:
 > use mythconverg;		# switch database
 > select * from settings;	# list settings or more precisely:
 > select value,data,hostname from settings;

On my pure BE/FE system, this gave 562 rows!
To check for conflicting entries on a single system, use:
 > select value,data,count(value) from settings group by value having 
count(value) > 1;

On my backend, this gave me 14 duplicate 'value' entries, including 
(weirdly) 'ArchiveDBSchemaVer' with 'data' equal "1004" in one entry and 
"1005" in the other! The others were pure duplicates. (Since there is no 
PrimaryKey, mysql does not choke on these duplicates.)

 > delete from settings where value = "ArchiveDBSchemaVer" and data = 
"1004";

Most had the same data value and I could drop one:
 > delete from settings where value = "TVVidModeResolution0" limit 1;

Then look at:
 > select value,data,hostname from settings where value like "%Server%";
This will show, among other things, the MasterServerIP and 
BackendServerIP addresses with hostname.
There should be no duplicates of those.

On a BE/FE machine you will have lots of entries where the hostname is 
"NULL". These a pure backend settings, as far as I can see.

HOWEVER, where you have slave backends, and separate frontends, you will 
have entries relating to each machine.
To separate each machine you can use:
 > select value,data,hostname,count(value) from settings group by value 
having count(value) > 1;
then
 > select value,data,hostname,count(value) from settings where hostname 
= "slave1.mydomain.org" group by value having count(value) > 1;

The first may show lots of 'duplicates' but the second will restrict 
each list to one slave.

Clean up any duplicates relating to each slave (or defunct machines!) 
and then:
 > select value,data,hostname from settings where 
hostname="slave1.mydomain.org;

I really have no idea what you will see in this sort of listing. For 
frontends, there will be all the VidMode and Resolution related entries. 
I assume that slave backends will have entries mapping things like the 
backend. The capturecard table has a 'hostname' field as does the 
storagegroup table.

One useful clause of the select command is:
 > select value,data from settings where value like "A%";
or
 > select value,data from settings where data like "%76%";
which returns values beginning with A or all the VidMode/GUI/Resolution 
entries which have height or screen sizes with '768' or '1350x768' etc.

And that's about all I know which could be useful. As noted, all my 
problems were with user authentication and I strongly suspect that that 
is your problem too. If each machine is a distinct mysql user (slave1, 
slave2, frontend1, livingroom etc) at least THAT possible error is 
averted. These are, after all, computers. The system is doing exactly 
what it has been told to do...just that we don't know what that was and 
it was wrong!

Hope this helps!
Geoff


              R. Geoffrey Newbury