[mythtv-users] MythSocket errors, backend unresponsive

Tue Aug 10 00:04:05 UTC 2010

First off, thanks R.G. that was all very concise and helpful information,
but I have a few issues with some of it (or should I say my setup does).

Let's say for just this response I have only the one MBE:

> > select host,user,password from user;   #Yes! there is a field called
> user, in a table called
>

...tells me I have mythtv@% and mythtv at tv (my MBE's hostname).  Per the
documentation (http://www.mythtv.org/docs/mythtv-HOWTO-6.html#ss6.2), one
could assume all I need is mythtv@% and generally makes sense for everywhere
else I've used MySQL.  However, the MBE won't start without mythtv at tvbecause:

2010-08-09 19:24:16.171 mythbackend version: branches/release-0-23-fixes
[25364] www.mythtv.org
2010-08-09 19:24:16.175 Using runtime prefix = /usr/local
2010-08-09 19:24:16.177 Using configuration directory = /home/mythtv/.mythtv
2010-08-09 19:24:16.178 Empty LocalHostName.
2010-08-09 19:24:16.182 Using localhost value of tv
2010-08-09 19:24:16.195 New DB connection, total: 1
2010-08-09 19:24:16.202 Unable to connect to database!
2010-08-09 19:24:16.203 Driver error was [1/1045]:
QMYSQL: Unable to connect
Database error was:
Access denied for user 'mythtv'@'tv' (using password: YES)

My config.txt says DBHostName=192.168.1.3 and config.xml says
<DBHostName>192.168.1.3</DBHostName>.

Shouldn't mythtv@% cover that?

Additionally, I have mythweb on my MBE.  MythWeb need mythtv at localhost in
MySQL when using setenv db_server "localhost" in mythweb.conf, else I need
to use the actual IP of the box setenv db_server "192.168.1.3" to satisfy
mythtv@%.

I didn't have any of the duplication issue you describe in your settings
table.  It seems as though this is an issue with MySQL more than MythTV, but
it's still unclear from the MythTV side how the MySQL calls have changed (if
that's even the issue) from the release I'm using now (-fixes r25364) to the
current release of -fixes.  Furthermore, if there is a change in how MySQL
is called from the backends, why doesn't it fail when the backend(s)
start(s), as opposed to some seemingly random point later on.

> 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
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20100809/f99e6581/attachment.htm>