[mythtv-users] Backend connections fail - stumped

[Craig Huff]

On Tue, Nov 14, 2023 at 8:38 PM Stephen Worthington <
stephen_agent at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20231117/9f7c3143/attachment.htm>