[mythtv-users] One step forward, two steps back - Frontends not woring properly

[Damian]

On 02/05/2016 17:21, Hika van den Hoven wrote:
> Hoi Hika,
>
> Monday, May 2, 2016, 6:10:45 PM, you wrote:
>
>> Hoi Damian,
>> Monday, May 2, 2016, 6:02:40 PM, you wrote:
>>> On 02/05/2016 15:42, Hika van den Hoven wrote:
>>>> Hoi Vincent,
>>>>
>>>> Monday, May 2, 2016, 3:52:16 PM, you wrote:
>>>>
>>>>> On Mon, May 02, 2016 at 12:18:02AM +0100, Damian wrote:
>>>>>> I have tried manually stopping and restarting the backend, and that didn't
>>>>>> fix things.
>>>>>>
>>>>>>> Posting the output of
>>>>>>>     initctl list
>>>>>>> should help clarify the situation
>>>>>> Here you go ...
>>>>>>
>>>>>> $ initctl list
>>>>>> indicator-application stop/waiting
>>>>>> unicast-local-avahi stop/waiting
>>>>>> update-notifier-crash stop/waiting
>>>>>> upstart-udev-bridge start/running, process 1438
>>>>>> update-notifier-hp-firmware stop/waiting
>>>>>> xsession-init stop/waiting
>>>>>> dbus start/running, process 1444
>>>>>> no-pinentry-gnome3 stop/waiting
>>>>>> update-notifier-cds stop/waiting
>>>>>> gnome-keyring-ssh stop/waiting
>>>>>> ssh-agent stop/waiting
>>>>>> upstart-dbus-session-bridge start/running, process 1493
>>>>>> gpg-agent start/running
>>>>>> indicator-messages stop/waiting
>>>>>> logrotate stop/waiting
>>>>>> im-config start/running
>>>>>> session-migration stop/waiting
>>>>>> upstart-dbus-system-bridge start/running, process 1491
>>>>>> at-spi2-registryd stop/waiting
>>>>>> startxfce4 start/running, process 1532
>>>>>> update-notifier-release stop/waiting
>>>>>> indicator-sound stop/waiting
>>>>>> upstart-file-bridge start/running, process 1501
>>>>>> gnome-keyring stop/waiting
>>>>>> re-exec stop/waiting
>>>>>> upstart-event-bridge stop/waiting
>>>>>>
>>>>>> Any problems/clues there?
>>>>>    
>>>>> I was flummoxed by this - no mention of myth or mysql in the output.
>>>>> But clearly they are starting up.
>>>>> Then I remembered you are on 16.04 - is it using systemd as the
>>>>> init system? You can tell if 'sudo which systemctl'
>>>>> returns e.g. /usr/sbin/systemctl or /sbin/systemctl.
>>>>> What I was trying to do here was get an idea of the relative order
>>>>> in which things are being started up. That's turning out to be tricky
>>>>> so we probably should not get distracted by the issue, but we may have
>>>>> to come back to it.
>>>>> Cheers
>>>>> Vince
>>>>> PS
>>>>> If you do have systemd installed you might be able to use it to
>>>>> get some information about the startup ordering, with
>>>>>     $ sudo systemd-analyze critical-chain mythbackend.service
>>>>>     $ sudo systemd-analyze critical-chain mysql.service
>>>>> see also [1] and [2]. I am not sure these commands will work,
>>>>> maybe others can supply the correct incantations.
>>>> I keep have the feeling that still backends are running on your
>>>> frontends a slave backend running without any tuner could give these
>>>> weird results.
>>>> What does:
>>>>
>>>> pgrep -l myth
>>>>
>>>> report? Or if you do not have pgrep:
>>>>
>>>> ps -A | grep myth
>>>>
>>>>
>>>> results
>>> Hi Hika,
>>> On the frontend machines, those commands return no results. Just goes to
>>> a new line in the terminal as though I had just pressed enter with no
>>> command at all.
>>> On the backend, I get ...
>>> $ pgrep -l myth
>>> 2145 mythbackend
>>> $ ps -A | grep myth
>>>    2145 ?        00:40:32 mythbackend
>>> Is that useful?
>>> Thanks,
>>> Damian
>> YES, there is a (slave)mythbackend running on that machine! So if
>> there is no tuner configured for that backend, it will keep
>> complaining and the master too, slowing everything down.
>> So you have to stop it and make sure it won't start again.
>> Unfortunatly I do not know the systemd syntax for that, but it will be
>> similar as you used to stop the frontend.
> Except of cause when you ran it on your backend machine. The it is OK
> ;-)
>
> That command shows all running services containing myth in their name.
>
>> Tot mails,
>>    Hika                            mailto:hikavdh at gmail.com

It's fixed! (hopefully)

I went back into the backend setup as I remembered that changing the 
entry in that IPv6 box changed things last time.

A few things have changed since then, so I wanted to go back in and see 
if changing the IPv6 setting would change things again. I assumed that 
it would make things worse, but knew that I cut put things back if needed.

I was surprised to find that there were 3 options for the IPv6 setting 
(see 
https://www.dropbox.com/s/twcih9pkd2sp4to/2016-05-02%2017_11_44-gingerserver_0%20-%20TigerVNC.png?dl=0). 


The one that worked was the default, "::1".

That wasn't working before, but obviously the changes we have made have 
altered things so that it can work!

I've now had the 2 remote frontends playing different media and grabbing 
meta-data for the last 15 minutes or so. All seems to be fine!!

Thanks for the help everyone. I'd be lots without you lot!!

Thanks again,
Damian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20160502/d8c9037e/attachment.html>