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

Fri Apr 29 21:54:50 UTC 2016

On 29/04/2016 22:31, Damian wrote:
> I LOVE MythTV when it's all set up and working properly.
>
> Is there anything more frustrating when it's not??
>
> OK, here's the latest problem. (all using Xubuntu 16.04, MythTV 0.28, 
> via Mythbuntu, all updates to latest versions etc).
>
> Things were going well. Server all set up. Backend working well. Local 
> frontend (on the server) seeming to work fine.
>
> One remote frontend set up and seeming fine.
>
> Second (main) remote frontend setup, but just wouldn't connect to the 
> backend! I couldn't work it out. Everything seemed fine, but it 
> couldn't connect.
>
> In desperation (never a good place to make decisions), I thought about 
> how Mythbuntu seems to install a slave backend (which I had removed on 
> the frontends) by default. So, I installed and set up slave backends 
> on both of the remote frontend machines.
>
> This seemed to work well. Now both remote frontends could connect and 
> I thought that I was heading in the right direction. However, now the 
> frontends were suddenly SO SLOW and couldn't connect to 'Videos' or 
> watch TV.
>
> After failing to fix this, I thought that the slave backends may have 
> been the problem, so I uninstalled them from both of the remote 
> frontends.
>
> This didn't change anything. I could still connect (so I was further 
> on than before I affed the slave backends), but everything was still 
> unusable.
>
> I tried changing the <LocalHostName> on one of the frontends to see if 
> being effectively a 'new user' would clean things up. It didn't. I was 
> just a new user with a system that was still broken.
>
> I ran one of the remote frontends from the command line to see what 
> error messages I was getting while things were freezing, and I got 
> lots of copies of messages like this ...
>
> 2016-04-29 21:49:14.102196 I MythCoreContext::ConnectCommandSocket(): 
> Connecting to backend server: 192.168.0.2:6543 (try 1 of 1)
> 2016-04-29 21:49:21.121452 E  MythSocket(3b91410:68): ReadStringList: 
> Error, timed out after 7000 ms.
> 2016-04-29 21:49:21.121843 C  Protocol version check failure.
>             The response to MYTH_PROTO_VERSION was empty.
>             This happens when the backend is too busy to respond,
>             or has deadlocked due to bugs or hardware failure.
> 2016-04-29 21:49:21.122406 W  Backend : gingerserver currently 
> Unreachable. Skipping this one.
> 2016-04-29 21:49:21.122558 I MythCoreContext::ConnectCommandSocket(): 
> Connecting to backend server: 192.168.0.2:6543
>
> I've just gone back to the server (backend system) and run the 
> frontend on there. Now that's having the same trouble. Almost 
> completely unresponsive. I haven't even touch this machine while I've 
> been trying other stuff!
>
> $ sudo service mythtv-backend status
>
> returns ...
>
> ● mythtv-backend.service - MythTV Backend
>    Loaded: loaded (/lib/systemd/system/mythtv-backend.service; 
> enabled; vendor preset: enabled)
>    Active: active (running) since Fri 2016-04-29 20:34:26 BST; 1h 
> 53min ago
>      Docs: https://www.mythtv.org/wiki/Mythbackend
>  Main PID: 822 (mythbackend)
>     Tasks: 34 (limit: 512)
>    CGroup: /system.slice/mythtv-backend.service
>            └─822 /usr/bin/mythbackend --quiet --syslog local7
>
> Apr 29 21:45:05 gingerserver mythbackend[822]: mythbackend[822]: I 
> TVRecEvent tv_rec.cpp:3685 (TuningFrequency) TVRec[3]: TuningFrequency
> Apr 29 21:50:18 gingerserver mythbackend[822]: mythbackend[822]: I 
> TVRecEvent tv_rec.cpp:3685 (TuningFrequency) TVRec[3]: TuningFrequency
> Apr 29 21:55:31 gingerserver mythbackend[822]: mythbackend[822]: I 
> TVRecEvent tv_rec.cpp:3685 (TuningFrequency) TVRec[3]: TuningFrequency
> Apr 29 22:00:43 gingerserver mythbackend[822]: mythbackend[822]: I 
> TVRecEvent tv_rec.cpp:3685 (TuningFrequency) TVRec[3]: TuningFrequency
> Apr 29 22:05:55 gingerserver mythbackend[822]: mythbackend[822]: I 
> TVRecEvent tv_rec.cpp:3685 (TuningFrequency) TVRec[3]: TuningFrequency
> Apr 29 22:11:08 gingerserver mythbackend[822]: mythbackend[822]: I 
> TVRecEvent tv_rec.cpp:3685 (TuningFrequency) TVRec[3]: TuningFrequency
> Apr 29 22:11:11 gingerserver mythbackend[822]: mythbackend[822]: E 
> TVRecEvent tv_rec.cpp:3964 (TuningSignalCheck) TVRec[3]: 
> TuningSignalCheck: SignalMonitor timed out
> Apr 29 22:14:14 gingerserver mythbackend[822]: mythbackend[822]: I 
> TVRecEvent tv_rec.cpp:3685 (TuningFrequency) TVRec[3]: TuningFrequency
> Apr 29 22:19:20 gingerserver mythbackend[822]: mythbackend[822]: I 
> TVRecEvent tv_rec.cpp:3685 (TuningFrequency) TVRec[3]: TuningFrequency
> Apr 29 22:24:25 gingerserver mythbackend[822]: mythbackend[822]: I 
> TVRecEvent tv_rec.cpp:3685 (TuningFrequency) TVRec[3]: TuningFrequency
>
> Any ideas?
>
> I had some mysql problems earlier, which I posted about, but they seem 
> to be resolved now. I can connect with both root and mythtv.
>
> My daughter is supposed to be having a cinema party fro her 16th 
> birthday on Wednesday. If I don't get this sorted, I'm 'bad dad', big 
> time. :-)
>
> Please let me know if you can see what's wrong or know what I should 
> do next.
>
> Thanks,
> Damian
Brief success, then back to failure.

Looking at the backend setup, I saw that I'd set the IPv6 address back 
to "::1". This must have been when I was trying and failing to get the 
second remote frontend to connect. I don't really know what that big 
long IPv6 address is (the one that's selectable on the backend), but 
must have assumed at some point that it should be moved away from the 
default value just as the IPv4 address needs to be changed.

Looking at https://www.mythtv.org/wiki/Setup_General indicates that I 
should have left this at the default value "::1", and I must have 
changed that earlier.

I just changed it back to the long IPv6 address, and suddenly everything 
was great, for about 3 minutes. All frontends connected fine, were 
responsive, and things looked good.

Then it all turned to sludge again.

Does this point to the source of the problem?

Thanks,
Damian