[mythtvnz] mythtvnz Digest, Vol 106, Issue 10

[Stephen Worthington]

On Sat, 6 Aug 2016 09:12:36 +1200, you wrote:

>> On Thu, 4 Aug 2016 20:00:53 +1200, you wrote:
>> 
>>> Upgrade to 16.04 and myth 0.28 and everything was working okay apart
>>>from mythweb which i don't really care about.
>>>
>>> mysql upgraded and now my backend is refusing connections from the frontend.
>>>
>>> I can watch live tv and recordings on my backend nut not accepting
>>> remote connections.
>>>
>>> Error message is
>>> mythsocket.cpp 739 Failed to connect connect to host (ip address)
>>> connection refused
>>>
>>> Output from netstat
>>> tcp        0      0 127.0.0.1:6543          0.0.0.0:*
>>> LISTEN      3657/mythbackend
>>> tcp        0      0 127.0.0.1:6544          0.0.0.0:*
>>> LISTEN      3657/mythbackend
>>> tcp        0      0 127.0.0.1:6549          0.0.0.0:*
>>> LISTEN      3657/mythbackend
>>> tcp        0      0 127.0.1.1:53            0.0.0.0:*
>>> LISTEN      3673/dnsmasq
>>> tcp        0      0 0.0.0.0:3000            0.0.0.0:*
>>> LISTEN      4937/ntop
>>> tcp        0      0 127.0.0.1:6554          0.0.0.0:*
>>> LISTEN      3657/mythbackend
>>>
>>> The ip address is correct any help welcome
>> 
>> Mythbackend seems to be listening on localhost only.  It needs to be
>> set to listen on all IP addresses (0.0.0.0) or on the external IP
>> address of the box.  But why would it have changed if it was working
>> before?
>> 
>> If you are happy with doing an SQL query, this should show you the
>> relevant settings:
>> 
>> mysql> select * from settings where value like '%ServerIP';
>> +-----------------+----------+----------+
>> | value           | data     | hostname |
>> +-----------------+----------+----------+
>> | MasterServerIP  | 10.0.2.4 | NULL     |
>> | BackendServerIP | 10.0.2.4 | mypvr    |
>> +-----------------+----------+----------+
>> 2 rows in set (0.00 sec)
>> 
>> Yours should look like mine (but with different IP addresses and
>> hostname), as we are both allowing external connections.  But it looks
>> like it will have 127.0.0.1 or localhost as the settings.
>> 
>> To get mythweb working, check if Apache is starting up.  There are
>> some config changes that may need to be made to get it to start.  Take
>> a look at the log files in /var/log/apache2 - probably error.log
>> first.>TRied looking at setting still no joy
>
>
>+ Options
>value 	data 	hostname 	
>BackendServerIP 192.168.2.177 	lothlorien
>MasterServerIP 	192.168.2.177 	NULL
>
>
>Looks fairly similar to yours.
>Just tried messing with my.cnf in /etc/mysql but still no joy connection
>still refused.
>
>Tried adding
>
>bind  192.168.2.177
>
>to the my.cnf file but made no difference. Been umable to watch tv for
>about 2 weeks now and almost ready to abandon this again.
>Bloody unreliable, recordings keep failing or really poor quality. Keep
>missing episodes of series. One of my tuners has just failed.

Adding or changing things in the my.cnf file will not work if they are
overridden by a later setting of the same option.  The my.cnf file
includes other .cnf files using the !includedir option as its last
line, so all the other .cnf files are read after it is read.  The
other files can also include more .cnf files.  In each !includedir,
the files are read from that directory in filesystem collating
sequence order (usually some approximation of alphanumeric order), so
one of those files read later than another will override prior
settings.

Since bind is often set in several of the .cnf files, changing it in
my.cnf is unlikely to work.  So you need to go to the /etc/mysql
directory and run this command:

  grep -ir bind *

which will show you all of the bind lines.  Only the ones that are not
commented out (# character at the start of the text) will do anything.
Then you need to work out which of them is the last one read, and
change that.  It can be easier to use one of two other strategies:

1) Comment out all the bind lines except one, and change that one to
what you want.

2) Work out which directory of .cnf files is read last, and in that
directory, create a new .cnf file that will be read last.  Using a
name like zzz_last.cnf should work.  Then put your bind line in that
file, and also use that file for any other new or changed settings you
want.

Your recording problems need a bit more information before we can help
much with them.  If you really do have a tuner that is or was failing,
then a lot of the problems will likely be caused by that.  MythTV does
not detect failed tuners except at startup and even then only if they
do not tune at all.  If a tuner stops working after startup, it will
still try to use it and the recordings scheduled on it will fail.  If
a tuner does work (ie obeys the commands sent to it), there can still
be reception problems due to aerial, cable and signal level
considerations.  Not all tuners are as sensitive as the best ones, and
as there are almost always multiple tuners, the signal from the aerial
is necessarily split to go to each and to any other devices such as
TVs.  Doing that wrong can leave one or more tuners with a signal it
can not work with properly.  TVs usually seem to work better than PC
tuners, but that is normally because they have been fed a better
signal, due to how the signal usually is split.  If you have a dual
tuner card, but it only has one aerial connection, then that card
necessarily has a builtin signal splitter and each of its tuners will
be getting slightly less than half the signal that a single tuner
would, and you need to take that into account when planning the aerial
connections.

Missing episodes can be from a number of problems, including your
failed tuner, but is often caused by the EPG providers not doing their
job and providing EPG that actually differentiates episodes from week
to week or day to day.  MythTV has lots of options to help with that,
but each case needs to be looked at individually and may need a
different fix.  And then may need to be fixed again if the EPG data
changes (as it often does, especially when repeats come along).