Mailing List Archive

On Mon, 13 Nov 2023 16:01:17 -0600, you wrote:

>My long running backend daemon has recently stopped accepting connections
>on port 6543. Even simply invoking "mythbackend --printsched" gets the
>cold shoulder. I've tried invoking the daemon with "-v all" and
>"--loglevel debug", but either I'm looking in the wrong log(s) or nothing
>is logged during these connection attempts.
>
>In short, the backend logs don't show anything at all when mythbackend,
>mythwelcome, and/or mythfrontend try to connect and the connecting
>applications' logs simply report that the connection, both by lan IP
>(192.168.x.x:6543) and local IP (127.0.0.1:6543) fail with messages like:
>
>2023-11-13 14:21:17.436230 I MythCoreContext: Connecting to backend
>server: 192.168.x.x:6543 (try 1 of 5)
>2023-11-13 14:21:17.436780 E MythSocket(abde80:-1): Failed to connect to (
>127.0.0.1:6543) Connection refused
>2023-11-13 14:22:17.523316 I MythCoreContext: Connecting to backend
>server: 192.168.x.x:6543 (try 2 of 5)
>2023-11-13 14:22:17.523815 E MythSocket(abde80:-1): Failed to connect to (
>127.0.0.1:6543) Connection refused

>I would greatly appreciate any help in figuring this out.

I presume that this is a frontend trying to connect to a separate
backend box.

The localhost connection attempt will always fail because there is no
mythbackend running on the frontend box.

The mythbackend log not showing any connection attempts suggests that
the traffic from the frontend box is not getting to mythbackend at
all. The frontend logs saying "Connection refused" suggests that port
6543 on the backend box is closed, but that the backend box is sending
a NAK packet when it receives a SYN packet to start a TCP connection
on that port - it is saying that the port is closed, rather than just
ignoring the SYN packet.

Does the backend box have a screen? Does mythfrontend work there? Is
port 6543 open on the backend box's IP address? Try running this on
the backend box:

sudo netstat -anp | grep 6543

Do you see a LISTEN line with 0.0.0.0, ::, or the specific IP address
of the box? If not, then you need to fix the mythbackend settings so
that it is listening for external connections.

From the frontend box, try manually connecting to the backend:

telnet <backend IP> 6543

This is the sort of thing you should see if it does connect:

root@crw-pvr:~# telnet mypvr.4.jsw.gen.nz 6543
Trying 10.0.2.4...
Connected to mypvr.4.jsw.gen.nz.
Escape character is '^]'.
^]
telnet> quit
Connection closed.

If it does not connect, but there is a LISTEN port open in the netstat
output, then there is likely a firewall on the backend machine (or
possibly the frontend machine) that is stopping the traffic, or there
is a routing problem in your network. Are you able to ping the
backend box from the frontend box?
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

> On 14 Nov 2023, at 11:44 am, Stephen Worthington <stephen_agent@jsw.gen.nz> wrote:
>
> On Mon, 13 Nov 2023 16:01:17 -0600, you wrote:
>
>> My long running backend daemon has recently stopped accepting connections
>> on port 6543. Even simply invoking "mythbackend --printsched" gets the
>> cold shoulder. I've tried invoking the daemon with "-v all" and
>> "--loglevel debug", but either I'm looking in the wrong log(s) or nothing
>> is logged during these connection attempts.
>>
>> In short, the backend logs don't show anything at all when mythbackend,
>> mythwelcome, and/or mythfrontend try to connect and the connecting
>> applications' logs simply report that the connection, both by lan IP
>> (192.168.x.x:6543) and local IP (127.0.0.1:6543) fail with messages like:
>>
>> 2023-11-13 14:21:17.436230 I MythCoreContext: Connecting to backend
>> server: 192.168.x.x:6543 (try 1 of 5)
>> 2023-11-13 14:21:17.436780 E MythSocket(abde80:-1): Failed to connect to (
>> 127.0.0.1:6543) Connection refused
>> 2023-11-13 14:22:17.523316 I MythCoreContext: Connecting to backend
>> server: 192.168.x.x:6543 (try 2 of 5)
>> 2023-11-13 14:22:17.523815 E MythSocket(abde80:-1): Failed to connect to (
>> 127.0.0.1:6543) Connection refused
>
>> I would greatly appreciate any help in figuring this out.
>
> I presume that this is a frontend trying to connect to a separate
> backend box.
>
> The localhost connection attempt will always fail because there is no
> mythbackend running on the frontend box.
>
> The mythbackend log not showing any connection attempts suggests that
> the traffic from the frontend box is not getting to mythbackend at
> all. The frontend logs saying "Connection refused" suggests that port
> 6543 on the backend box is closed, but that the backend box is sending
> a NAK packet when it receives a SYN packet to start a TCP connection
> on that port - it is saying that the port is closed, rather than just
> ignoring the SYN packet.
>
> Does the backend box have a screen? Does mythfrontend work there? Is
> port 6543 open on the backend box's IP address? Try running this on
> the backend box:
>
> sudo netstat -anp | grep 6543
>
> Do you see a LISTEN line with 0.0.0.0, ::, or the specific IP address
> of the box? If not, then you need to fix the mythbackend settings so
> that it is listening for external connections.
>
> From the frontend box, try manually connecting to the backend:
>
> telnet <backend IP> 6543
>
> This is the sort of thing you should see if it does connect:
>
> root@crw-pvr:~# telnet mypvr.4.jsw.gen.nz 6543
> Trying 10.0.2.4...
> Connected to mypvr.4.jsw.gen.nz.
> Escape character is '^]'.
> ^]
> telnet> quit
> Connection closed.
>
> If it does not connect, but there is a LISTEN port open in the netstat
> output, then there is likely a firewall on the backend machine (or
> possibly the frontend machine) that is stopping the traffic, or there
> is a routing problem in your network. Are you able to ping the
> backend box from the frontend box?

Steven gives you nice step-1’s
How about step-0
On backend machine is backend running ?

$ ps -ef |grep myth

How do you start the backend? eg for systemd

$ systemctl status mythbackend

What is the last thing logged? in normal backend logs.

James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, Nov 13, 2023 at 10:16?PM jam <jam@tigger.ws> wrote:

>
>
> > On 14 Nov 2023, at 11:44 am, Stephen Worthington <
> stephen_agent@jsw.gen.nz> wrote:
> >
> > On Mon, 13 Nov 2023 16:01:17 -0600, you wrote:
> >
> >> My long running backend daemon has recently stopped accepting
> connections
> >> on port 6543. Even simply invoking "mythbackend --printsched" gets the
> >> cold shoulder. I've tried invoking the daemon with "-v all" and
> >> "--loglevel debug", but either I'm looking in the wrong log(s) or
> nothing
> >> is logged during these connection attempts.
> >>
> >> In short, the backend logs don't show anything at all when mythbackend,
> >> mythwelcome, and/or mythfrontend try to connect and the connecting
> >> applications' logs simply report that the connection, both by lan IP
> >> (192.168.x.x:6543) and local IP (127.0.0.1:6543) fail with messages
> like:
> >>
> >> 2023-11-13 14:21:17.436230 I MythCoreContext: Connecting to backend
> >> server: 192.168.x.x:6543 (try 1 of 5)
> >> 2023-11-13 14:21:17.436780 E MythSocket(abde80:-1): Failed to connect
> to (
> >> 127.0.0.1:6543) Connection refused
> >> 2023-11-13 14:22:17.523316 I MythCoreContext: Connecting to backend
> >> server: 192.168.x.x:6543 (try 2 of 5)
> >> 2023-11-13 14:22:17.523815 E MythSocket(abde80:-1): Failed to connect
> to (
> >> 127.0.0.1:6543) Connection refused
> >
> >> I would greatly appreciate any help in figuring this out.
> >
> > I presume that this is a frontend trying to connect to a separate
> > backend box.
> >
> > The localhost connection attempt will always fail because there is no
> > mythbackend running on the frontend box.
> >
> > The mythbackend log not showing any connection attempts suggests that
> > the traffic from the frontend box is not getting to mythbackend at
> > all. The frontend logs saying "Connection refused" suggests that port
> > 6543 on the backend box is closed, but that the backend box is sending
> > a NAK packet when it receives a SYN packet to start a TCP connection
> > on that port - it is saying that the port is closed, rather than just
> > ignoring the SYN packet.
> >
> > Does the backend box have a screen? Does mythfrontend work there? Is
> > port 6543 open on the backend box's IP address? Try running this on
> > the backend box:
> >
> > sudo netstat -anp | grep 6543
> >
> > Do you see a LISTEN line with 0.0.0.0, ::, or the specific IP address
> > of the box? If not, then you need to fix the mythbackend settings so
> > that it is listening for external connections.
> >
> > From the frontend box, try manually connecting to the backend:
> >
> > telnet <backend IP> 6543
> >
> > This is the sort of thing you should see if it does connect:
> >
> > root@crw-pvr:~# telnet mypvr.4.jsw.gen.nz 6543
> > Trying 10.0.2.4...
> > Connected to mypvr.4.jsw.gen.nz.
> > Escape character is '^]'.
> > ^]
> > telnet> quit
> > Connection closed.
> >
> > If it does not connect, but there is a LISTEN port open in the netstat
> > output, then there is likely a firewall on the backend machine (or
> > possibly the frontend machine) that is stopping the traffic, or there
> > is a routing problem in your network. Are you able to ping the
> > backend box from the frontend box?
>
> Steven gives you nice step-1’s
> How about step-0
> On backend machine is backend running ?
>
> $ ps -ef |grep myth
>
> How do you start the backend? eg for systemd
>
> $ systemctl status mythbackend
>
> What is the last thing logged? in normal backend logs.
>
> James
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org


Thank you for your responses. It seems there's always something
important/useful that I fail to mention. This is the combined
frontend/backend server with mythbackend and mysql services and the
frontend I use for administering the recording scheduling. I have several
other computers that I use as frontend-only systems, however they're
off-line for various reasons -- even if the current problem hadn't cropped
up.

I have stopped/started/restarted the mythtv-backend service multiple times,
as well as rebooted the system with impunity, since it's not working as far
as I can tell. I tried stopping the backend, then starting it and promptly
started a mythwelcome instance to see what kind of messages I could find in
/var/log/mythtv/mythwelcome.log, mythbackend.log, and mythfrontend.log by
having multiple xterms open with "tail -f mythxxx" running for each log,
but nothing enlightening came of that, hence the shout out for help.

I tried the netstat command as advised by Stephen, and got no response at
all. It just came immediately back to the command prompt. Since the
system had been working for a long time (years), and I haven't done
anything on the system in quite some time besides review upcoming shows and
delete some old recordings, I have no idea why the backend isn't listening
on the port or what to do to fix it. I would appreciate any guidance on
what to do next. I don't recall any config file that affected the
mythbackend settings, but it's been a long time since I set it up. On the
off-chance that would involve /root/.mythtv/config.xml, here are the
contents (which are the same for the ~mythtv home-path and the general user
home-path):

<Configuration>
<Database>
<PingHost>1</PingHost>
<Host>192.168.1.149</Host>
<UserName>mythtv</UserName>
<Password>********</Password>
<DatabaseName>mythconverg</DatabaseName>
<Port>3306</Port>
</Database>
<WakeOnLAN>
<Enabled>0</Enabled>
<SQLReconnectWaitTime>0</SQLReconnectWaitTime>
<SQLConnectRetry>5</SQLConnectRetry>
<Command>echo 'WOLsqlServerCommand not set'</Command>
</WakeOnLAN>
<UPnP>
<UDN>
<MediaRenderer>f9e82f4e-fb8c-433e-8bc7-258c8d74c95c</MediaRenderer>
</UDN>
</UPnP>
<LocalHostName>penguin</LocalHostName>
</Configuration>

Thanks again for any help you can provide.

--
Craig.

On Tue, 14 Nov 2023 18:15:17 -0600, you wrote:

>On Mon, Nov 13, 2023 at 10:16?PM jam <jam@tigger.ws> wrote:
>
>>
>>
>> > On 14 Nov 2023, at 11:44 am, Stephen Worthington <
>> stephen_agent@jsw.gen.nz> wrote:
>> >
>> > On Mon, 13 Nov 2023 16:01:17 -0600, you wrote:
>> >
>> >> My long running backend daemon has recently stopped accepting
>> connections
>> >> on port 6543. Even simply invoking "mythbackend --printsched" gets the
>> >> cold shoulder. I've tried invoking the daemon with "-v all" and
>> >> "--loglevel debug", but either I'm looking in the wrong log(s) or
>> nothing
>> >> is logged during these connection attempts.
>> >>
>> >> In short, the backend logs don't show anything at all when mythbackend,
>> >> mythwelcome, and/or mythfrontend try to connect and the connecting
>> >> applications' logs simply report that the connection, both by lan IP
>> >> (192.168.x.x:6543) and local IP (127.0.0.1:6543) fail with messages
>> like:
>> >>
>> >> 2023-11-13 14:21:17.436230 I MythCoreContext: Connecting to backend
>> >> server: 192.168.x.x:6543 (try 1 of 5)
>> >> 2023-11-13 14:21:17.436780 E MythSocket(abde80:-1): Failed to connect
>> to (
>> >> 127.0.0.1:6543) Connection refused
>> >> 2023-11-13 14:22:17.523316 I MythCoreContext: Connecting to backend
>> >> server: 192.168.x.x:6543 (try 2 of 5)
>> >> 2023-11-13 14:22:17.523815 E MythSocket(abde80:-1): Failed to connect
>> to (
>> >> 127.0.0.1:6543) Connection refused
>> >
>> >> I would greatly appreciate any help in figuring this out.
>> >
>> > I presume that this is a frontend trying to connect to a separate
>> > backend box.
>> >
>> > The localhost connection attempt will always fail because there is no
>> > mythbackend running on the frontend box.
>> >
>> > The mythbackend log not showing any connection attempts suggests that
>> > the traffic from the frontend box is not getting to mythbackend at
>> > all. The frontend logs saying "Connection refused" suggests that port
>> > 6543 on the backend box is closed, but that the backend box is sending
>> > a NAK packet when it receives a SYN packet to start a TCP connection
>> > on that port - it is saying that the port is closed, rather than just
>> > ignoring the SYN packet.
>> >
>> > Does the backend box have a screen? Does mythfrontend work there? Is
>> > port 6543 open on the backend box's IP address? Try running this on
>> > the backend box:
>> >
>> > sudo netstat -anp | grep 6543
>> >
>> > Do you see a LISTEN line with 0.0.0.0, ::, or the specific IP address
>> > of the box? If not, then you need to fix the mythbackend settings so
>> > that it is listening for external connections.
>> >
>> > From the frontend box, try manually connecting to the backend:
>> >
>> > telnet <backend IP> 6543
>> >
>> > This is the sort of thing you should see if it does connect:
>> >
>> > root@crw-pvr:~# telnet mypvr.4.jsw.gen.nz 6543
>> > Trying 10.0.2.4...
>> > Connected to mypvr.4.jsw.gen.nz.
>> > Escape character is '^]'.
>> > ^]
>> > telnet> quit
>> > Connection closed.
>> >
>> > If it does not connect, but there is a LISTEN port open in the netstat
>> > output, then there is likely a firewall on the backend machine (or
>> > possibly the frontend machine) that is stopping the traffic, or there
>> > is a routing problem in your network. Are you able to ping the
>> > backend box from the frontend box?
>>
>> Steven gives you nice step-1?s
>> How about step-0
>> On backend machine is backend running ?
>>
>> $ ps -ef |grep myth
>>
>> How do you start the backend? eg for systemd
>>
>> $ systemctl status mythbackend
>>
>> What is the last thing logged? in normal backend logs.
>>
>> James
>
>Thank you for your responses. It seems there's always something
>important/useful that I fail to mention. This is the combined
>frontend/backend server with mythbackend and mysql services and the
>frontend I use for administering the recording scheduling. I have several
>other computers that I use as frontend-only systems, however they're
>off-line for various reasons -- even if the current problem hadn't cropped
>up.
>
>I have stopped/started/restarted the mythtv-backend service multiple times,
>as well as rebooted the system with impunity, since it's not working as far
>as I can tell. I tried stopping the backend, then starting it and promptly
>started a mythwelcome instance to see what kind of messages I could find in
>/var/log/mythtv/mythwelcome.log, mythbackend.log, and mythfrontend.log by
>having multiple xterms open with "tail -f mythxxx" running for each log,
>but nothing enlightening came of that, hence the shout out for help.
>
>I tried the netstat command as advised by Stephen, and got no response at
>all. It just came immediately back to the command prompt. Since the
>system had been working for a long time (years), and I haven't done
>anything on the system in quite some time besides review upcoming shows and
>delete some old recordings, I have no idea why the backend isn't listening
>on the port or what to do to fix it. I would appreciate any guidance on
>what to do next. I don't recall any config file that affected the
>mythbackend settings, but it's been a long time since I set it up. On the
>off-chance that would involve /root/.mythtv/config.xml, here are the
>contents (which are the same for the ~mythtv home-path and the general user
>home-path):

If that netstat command is producing no output, then mythbackend is
not listening on port 6543 at all, even on localhost. So that is the
basic problem.

So, is mythbackend even running? What is the output of:

sudo ps -ef | grep -i myth

Is this an Ubuntu system? If so, or it uses systemd, then look at the
output of:

sudo systemctl status mythtv-backend

This is what I get on my system (Ubuntu 22.04):

? mythtv-backend.service - MythTV Backend
Loaded: loaded (/lib/systemd/system/mythtv-backend.service;
enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/mythtv-backend.service.d
+-mythtv-backend-override.conf
Active: active (running) since Mon 2023-11-13 23:31:38 NZDT; 1
day 16h ago
Docs: https://www.mythtv.org/wiki/Mythbackend
Main PID: 1615074 (mythbackend)
Status: "Master backend. Recordings: active 0, scheduled 165"
Tasks: 62 (limit: 38309)
Memory: 2.4G
CPU: 1h 16min 1.931s
CGroup: /system.slice/mythtv-backend.service
+-1615074 /usr/bin/mythbackend --quiet --syslog local7 -v
record,dvbcam

Nov 15 15:19:31 mypvr mythbackend[1615074]: mythbackend[1615074]: I
ProcessRequest mainserver.cpp:1814 (HandleAnnounce) MainServer:
MainServer::ANN Monitor
Nov 15 15:19:31 mypvr mythbackend[1615074]: mythbackend[1615074]: I
ProcessRequest mainserver.cpp:1816 (HandleAnnounce) MainServer:
adding: mypvr(55bd1691cf90) as a client (events: 0)
Nov 15 15:19:31 mypvr mythbackend[1615074]: mythbackend[1615074]: I
MythSocketThread(82) mainserver.cpp:7899 (connectionClosed) Monitor
sock(55bd1691cf90) 'mypvr' disconnected
Nov 15 15:20:01 mypvr mythbackend[1615074]: mythbackend[1615074]: I
ProcessRequest mainserver.cpp:1814 (HandleAnnounce) MainServer:
MainServer::ANN Monitor
Nov 15 15:20:01 mypvr mythbackend[1615074]: mythbackend[1615074]: I
ProcessRequest mainserver.cpp:1816 (HandleAnnounce) MainServer:
adding: mypvr(55bd1691cf90) as a client (events: 0)
Nov 15 15:20:01 mypvr mythbackend[1615074]: mythbackend[1615074]: I
MythSocketThread(82) mainserver.cpp:7899 (connectionClosed) Monitor
sock(55bd1691cf90) 'mypvr' disconnected
Nov 15 15:25:12 mypvr mythbackend[1615074]: mythbackend[1615074]: N
Expire autoexpire.cpp:244 (CalcParams) AutoExpire: CalcParams(): Max
required Free Space: 1.0 GB w/freq: 15 min
Nov 15 15:30:02 mypvr mythbackend[1615074]: mythbackend[1615074]: I
ProcessRequest mainserver.cpp:1814 (HandleAnnounce) MainServer:
MainServer::ANN Monitor
Nov 15 15:30:02 mypvr mythbackend[1615074]: mythbackend[1615074]: I
ProcessRequest mainserver.cpp:1816 (HandleAnnounce) MainServer:
adding: mypvr(55bd1691da80) as a client (events: 0)
Nov 15 15:30:02 mypvr mythbackend[1615074]: mythbackend[1615074]: I
MythSocketThread(82) mainserver.cpp:7899 (connectionClosed) Monitor
sock(55bd1691da80) 'mypvr' disconnected

It should say "Active: active (running) since" and tell you how long.

If you see mythbackend running in that output, then what is the output
of:

sudo netstat -anp | grep -i myth

and check the /var/log/mythtv/mythbackend.log file and the output of:

sudo journalctl -eu mythtv-backend

for information on what mythbackend is doing.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, Nov 14, 2023 at 8:38?PM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

>
> <snip>
>
> If that netstat command is producing no output, then mythbackend is
> not listening on port 6543 at all, even on localhost. So that is the
> basic problem.
>
> So, is mythbackend even running? What is the output of:
>
> sudo ps -ef | grep -i myth
>
> Is this an Ubuntu system? If so, or it uses systemd, then look at the
> output of:
>
> sudo systemctl status mythtv-backend
>
> This is what I get on my system (Ubuntu 22.04):
>
> ? mythtv-backend.service - MythTV Backend
> Loaded: loaded (/lib/systemd/system/mythtv-backend.service;
> enabled; vendor preset: enabled)
> Drop-In: /etc/systemd/system/mythtv-backend.service.d
> +-mythtv-backend-override.conf
> Active: active (running) since Mon 2023-11-13 23:31:38 NZDT; 1
> day 16h ago
> Docs: https://www.mythtv.org/wiki/Mythbackend
> Main PID: 1615074 (mythbackend)
> Status: "Master backend. Recordings: active 0, scheduled 165"
> Tasks: 62 (limit: 38309)
> Memory: 2.4G
> CPU: 1h 16min 1.931s
> CGroup: /system.slice/mythtv-backend.service
> +-1615074 /usr/bin/mythbackend --quiet --syslog local7 -v
> record,dvbcam
>
> Nov 15 15:19:31 mypvr mythbackend[1615074]: mythbackend[1615074]: I
> ProcessRequest mainserver.cpp:1814 (HandleAnnounce) MainServer:
> MainServer::ANN Monitor
> Nov 15 15:19:31 mypvr mythbackend[1615074]: mythbackend[1615074]: I
> ProcessRequest mainserver.cpp:1816 (HandleAnnounce) MainServer:
> adding: mypvr(55bd1691cf90) as a client (events: 0)
> Nov 15 15:19:31 mypvr mythbackend[1615074]: mythbackend[1615074]: I
> MythSocketThread(82) mainserver.cpp:7899 (connectionClosed) Monitor
> sock(55bd1691cf90) 'mypvr' disconnected
> Nov 15 15:20:01 mypvr mythbackend[1615074]: mythbackend[1615074]: I
> ProcessRequest mainserver.cpp:1814 (HandleAnnounce) MainServer:
> MainServer::ANN Monitor
> Nov 15 15:20:01 mypvr mythbackend[1615074]: mythbackend[1615074]: I
> ProcessRequest mainserver.cpp:1816 (HandleAnnounce) MainServer:
> adding: mypvr(55bd1691cf90) as a client (events: 0)
> Nov 15 15:20:01 mypvr mythbackend[1615074]: mythbackend[1615074]: I
> MythSocketThread(82) mainserver.cpp:7899 (connectionClosed) Monitor
> sock(55bd1691cf90) 'mypvr' disconnected
> Nov 15 15:25:12 mypvr mythbackend[1615074]: mythbackend[1615074]: N
> Expire autoexpire.cpp:244 (CalcParams) AutoExpire: CalcParams(): Max
> required Free Space: 1.0 GB w/freq: 15 min
> Nov 15 15:30:02 mypvr mythbackend[1615074]: mythbackend[1615074]: I
> ProcessRequest mainserver.cpp:1814 (HandleAnnounce) MainServer:
> MainServer::ANN Monitor
> Nov 15 15:30:02 mypvr mythbackend[1615074]: mythbackend[1615074]: I
> ProcessRequest mainserver.cpp:1816 (HandleAnnounce) MainServer:
> adding: mypvr(55bd1691da80) as a client (events: 0)
> Nov 15 15:30:02 mypvr mythbackend[1615074]: mythbackend[1615074]: I
> MythSocketThread(82) mainserver.cpp:7899 (connectionClosed) Monitor
> sock(55bd1691da80) 'mypvr' disconnected
>
> It should say "Active: active (running) since" and tell you how long.
>
> If you see mythbackend running in that output, then what is the output
> of:
>
> sudo netstat -anp | grep -i myth
>
> and check the /var/log/mythtv/mythbackend.log file and the output of:
>
> sudo journalctl -eu mythtv-backend
>
> for information on what mythbackend is doing.
> _______________________________________________
>
> Sorry for the delay in responding with an update. Life does that.

Anyway, I was doing tests trying to collect useful log data and translate
your suggested test commands back to my admittedly ancient Upstart based
Ubuntu environment. The first run of 'netstat -anp | grep -i myth' showed
no lines about port 6543, but I didn't think to capture the output. Also,
I wanted to get the maximum information in the log, so I stopped
mythbackend and restarted it with the added options '--loglevel debug -v
all'.

Naturally, as always happens when I'm ready to capture details of a
problem, there is no problem. The backend has been working. Even after I
reverted to running it without all the extra data logging. Well, sort of.
It is responding to port communications, like 'mythbackend --sched' and
getting this master FE/BE system's mythfrontend to connect. Everything
(administratively, at least) works. However, recordings that come up based
on the existing recording rules don't capture anything. The files are
empty.

I tried today to use the frontend's "Watch TV" option and every channel I
tried failed to get a lock. This was even true on channels carrying things
like "Hazel" or "Dennis the Menace". I then went to the web interface
pages for the Ceton and the CableCARD page implies that either it has
gotten out of sync with the Xfinity feed or it has gone belly up. The
webpage says the card is inserted, but the data items are "unavailable", 0,
etc. The card authorization status is reported as "Card is busy with
binding authentication process".

This makes me think it's not a matter of synchronization and more an issue
with the CableCARD breathing its last. At this point, I'm suspecting that
mythbackend got tied up in knots with some kind of message storm because it
couldn't successfully communicate with the Ceton tuner box. My next move
is to arrange with Xfinity to swap the CableCard for a "known good" unit,
although I doubt that they really "know" the one they will supply me is
good. I'll likely be testing it out for them.

I'll get back in a while with updates, but with the Thanksgiving holiday
coming up here in the States, it may take awhile to get a replacement
CableCARD and have the time to get it working (or not). I'll post again
when I have news.

Thanks for pointing me in the right direction, even when it takes a U-turn
to make progress. ????

--
Craig.