[SOLVED] - mythbackend will not connect to host 127.0.0.1

[white_haired_uncle]

It is looking like for some reason my Slackware machine will not accept a connection on either the 10. address or the localhost, 127.0.0.1, on port 6543. I thought maybe the firewall was blocking that port, but I turned it off and still no joy.

It won't accept connection on that port unless something is listening on that port (which nothing is, as we saw from netstat).

Then as I looked further all the configuration for my hdhomerun tuners was gone so I had to re-program them under Capture Cards and set up the Video Sources, Input Connections, and add the Storage Directories back.

As part of the Slackware update process, did you also update mythtv? IIRC, hdhr tuners had to be reconfigured around v31 or so. If so, do you know that old version? Maybe 28?

Is the database you've restored from said previous version?

[rocknrobin72]

bill6502...I manually edited the BackendServer IP to the 10.160.134.60 address.

Code: Select all

MariaDB [mythconverg]> SELECT * FROM settings WHERE value IN ('BackendServerIP', 'BackendServerIP6', 'BackendServerAddr', 'MasterServerIP', 'MasterServerName') ORDER BY hostname,value;
+-------------------+-----------------------------+-----------------------------+
| value             | data                        | hostname                    |
+-------------------+-----------------------------+-----------------------------+
| MasterServerIP    | 10.160.134.60               | NULL                        |
| MasterServerName  | robrutrm.marsinnovations.us | NULL                        |
| BackendServerAddr | 10.160.134.60               | robrutrm.marsinnovations.us |
| BackendServerIP   | 10.160.134.60               | robrutrm.marsinnovations.us |
| BackendServerIP6  | ::1                         | robrutrm.marsinnovations.us |
+-------------------+-----------------------------+-----------------------------+
5 rows in set (0.001 sec)

with the same results when trying to start the backend:

Code: Select all

2023-05-01 10:45:35.548901 I [18288/18288] CoreContext mythtranslation.cpp:62 (load) - Loading en_us translation for module mythfrontend
2023-05-01 10:45:35.549411 I [18288/18288] CoreContext mythcorecontext.cpp:488 (ConnectCommandSocket) - MythCoreContext::ConnectCommandSocket(): Connecting to backend server: 10.160.134.60:6543 (try 1 of 1)
2023-05-01 10:45:35.549649 E [18288/18393] MythSocketThread(-1) mythsocket.cpp:686 (ConnectToHostReal) - MythSocket(c15720:-1): Failed to connect to (127.0.0.1:6543) Connection refused
2023-05-01 10:45:35.549687 E [18288/18288] CoreContext mythcorecontext.cpp:556 (ConnectCommandSocket) - Connection to master server timed out.
                        Either the server is down or the master server settings
                        in mythtv-settings does not contain the proper IP address

2023-05-01 10:45:35.549689 E [18288/18288] CoreContext main_helpers.cpp:377 (handle_command) - Unable to connect to backend, log level unchanged

Even though I was able to change the BackendServer IP to my 10. address it is still trying to connect to 127.0.0.1. I don't see anywhere in mythtv-setup to change that so I'm not sure how that can be accomplished. Before all this started I had always run my Primary IP address/DNS name as 127.0.0.1 and the backend would still start and I could connect to it from a different machine than this one.

[white_haired_uncle]

Even though I was able to change the BackendServer IP to my 10. address it is still trying to connect to 127.0.0.1. I don't see anywhere in mythtv-setup to change that so I'm not sure how that can be accomplished. Before all this started I had always run my Primary IP address/DNS name as 127.0.0.1 and the backend would still start and I could connect to it from a different machine than this one.

There are a number of places where if a value is missing or can't be determined, it defaults to localhost (127.0.0.1), so you may never find it in the setup or mysql.

Personally, I think this is a bit of a red herring. I don't think the issue is that it can't connect to 127.0.0.1 (or anything else for that matter). I think the issue is that it shouldn't be trying to in the first place. This is the master backend server, it shouldn't be trying to connect to someone else, it should be starting up as a master (which includes opening that port and listening for connections). In the case of a single backend system in particular, if the master has to connect to "someone else" before it will start, it's never going to start because it's the only one it could connect to (that makes sense in my head, trust me -- a little -- if it helps think of the chicken and the egg).

Again, at the point yours starts trying to connect to "someone else", in my log it says "Starting up as a master" (or something very close to that).

So I'm trying to follow the start up process under the theory that your machine doesn't recognize that it's (supposed to be) the master. Honestly, I'm lost at this point, it sure looks like it should be working (not trying to connect, but starting), though it may help to know the schema of the database you're currently using (it's in the settings table), or even just what myth version the database backup was created by.

BTW, you might try setting BackendServerAddr to robrutrm.marsinnovations.us, or just robrutrm (I'd try each of them). That's the way mine is set up. I don't think this is the problem, though it might help point to the problem if it should happen to work.

[rocknrobin72]

Yes white_haired_uncle I believe you are on to something. This is the last log I could find where the backend started and as can be seen it starts off specifying the MythTV Schema version, 1376, then Loading en_us translation, and then "starting up as the master server.".

Code: Select all

2023-04-25 18:25:24.964404 E [4075/4075] CoreContext mythpowerdbus.cpp:103 (Init) - PowerDBus: No UPower interface. Unable to monitor battery state
2023-04-25 18:25:25.015093 I [4075/4075] CoreContext mythpowerdbus.cpp:540 (AcquireLock) - PowerDBus: Failed to delay sleep,shutdown: Launch helper exited with unknown return code 1
2023-04-25 18:25:25.265439 I [4075/4075] CoreContext mythpower.cpp:354 (PowerLevelChanged) - Power: On AC power
2023-04-25 18:25:25.265451 I [4075/4075] CoreContext mythpower.cpp:136 (Init) - Power: Supported actions: None
2023-04-25 18:25:25.266547 I [4075/4075] CoreContext mythtranslation.cpp:62 (load) - Loading en_us translation for module mythfrontend
2023-04-25 18:25:25.269162 I [4075/4075] CoreContext schemawizard.cpp:117 (Compare) - Current MythTV Schema Version (DBSchemaVer): 1376
2023-04-25 18:25:25.269423 I [4075/4075] CoreContext mythtranslation.cpp:62 (load) - Loading en_us translation for module mythfrontend
2023-04-25 18:25:25.270205 N [4075/4075] CoreContext mythbackend_main_helpers.cpp:635 (run_backend) - MythBackend: Starting up as the master server.
2023-04-25 18:25:25.314336 I [4075/4075] CoreContext hdhrstreamhandler.cpp:394 (Connect) - HDHRSH[6](1019344C): Added 2 devices from 1019344C
2023-04-25 18:25:25.375457 I [4075/4075] CoreContext hdhrstreamhandler.cpp:411 (Connect) - HDHRSH[6](1019344C): Connected to device(1019344C-1)

Bill...maybe you could tell us why this "new" scenario is causing the local machine to connect to some thing else and not just running the mythbackend_main_helpers.cpp routine to start locally.

white_haired_uncle...I have always created my database backups on the same machine with the perl scripts provided on the MythTV wiki page. They actually specify the database Schema version in the name of the backup. I am running ver 32/fixes so I believe that schema has to follow with the version. Every time I've upgraded the database Schema version changed.

[bill6502]

Before DBSchemaVer 1347 the MasterServerIP and BackendServerIP or 6 were compared and if they matched,
then it was a master. Now, we just look at MasterServerName. So let's check these just to rule things out:

Code: Select all

SELECT * FROM settings WHERE value IN ('MasterServerName','DBSchemaVer');

The output from this will be in /tmp, please let the command run for 10 seconds and press control-c.
Put the log at pastebin.com (or wherever you have a public readable site.) Just in case it's too big for
here. Add the link to it here.

I'd like to see a full log, with added verbose/debug. Plus clean the cache and tmp directories (I
agree that something is pulling in the 127... address, or it's being generated internally.) It doesn't
look like the backend is getting very far from the log fragments above.

Code: Select all

sudo systemctl stop mythtv-backend.service (or whatever you use)
sudo rm -rf ~mythtv/.mythtv/{cache,tmp}/*
sudo mythbackend --user=mythtv --verbose=most,norefcount --loglevel=debug --logpath=/tmp --quiet

[white_haired_uncle]

After you get Bill's stuff...

Did the master's IP change before or after that log where things were working?

grep host /etc/nsswitch.conf

[rocknrobin72]

bill6502...here is the output you requested.

Code: Select all

MariaDB [mythconverg]> SELECT * FROM settings WHERE value IN ('MasterServerName','DBSchemaVer');
+------------------+-----------------------------+----------+
| value            | data                        | hostname |
+------------------+-----------------------------+----------+
| DBSchemaVer      | 1376                        | NULL     |
| MasterServerName | robrutrm.marsinnovations.us | NULL     |
+------------------+-----------------------------+----------+
2 rows in set (0.001 sec)

Here is the link to the log you requested with verbose debug data:
https://www.dropbox.com/sh/i6hzhs054c31 ... MvQ6a?dl=0

Uncle Bob...I can't honestly answer you question about the master's IP changing before or after it quit working. In mythtv-setup the Primary IP address was 127.0.0.1, which is what it has always been since I got it working. I don't if that's the same thing or not from what I see in the mythconverg database. I started changing the address to the 10. address when mythbackend would not start. Here's what you requested.

Code: Select all

/mythtv# grep host /etc/nsswitch.conf
hosts:          files dns

[bill6502]

OK.

2023-05-01 20:31:41.174666 N [22337/22337] CoreContext main_helpers.cpp:634 (run_backend) - MythBackend: Starting up as the master server.
...
2023-05-01 20:31:41.711847 I [22337/22337] CoreContext serverpool.cpp:415 (listen) - Listening on TCP 0.0.0.0:6543

It's not a master issue. It is starting as one and it is listening on 0.0.0.0

At least that's true when started from the command line.

Can we see a full log when the failure occurs.

To get the enhanced logging at startup (without modifying the .service file) you can pass additional
options in /etc/mythtv/additional.args. Add the next line in that file, creating the file if it's not
there.

Code: Select all

ADDITIONAL_ARGS="--verbose=most,norefcount --loglevel=debug --logpath=/tmp"

Make sure your .service file contains lines like these (from systemctl cat mythtv-backend.service)

Code: Select all

EnvironmentFile=-/etc/mythtv/additional.args
ExecStart=/usr/local/bin/mythbackend --logpath /var/log/mythtv --quiet \
          $ADDITIONAL_ARGS

This time, you need to keep it running 'til the failure occurs.

Just comment out the ADDITIONAL_ARGS line and restart the backend to clear the additional logging.

[white_haired_uncle]

Uncle Bob...I can't honestly answer you question about the master's IP changing before or after it quit working. In mythtv-setup the Primary IP address was 127.0.0.1, which is what it has always been since I got it working. I don't if that's the same thing or not from what I see in the mythconverg database. I started changing the address to the 10. address when mythbackend would not start. Here's what you requested.

A couple weeks ago, your master's IP was 10.160.134.69, now it's .60. I was just wondering how/when that change related to the backend not starting. I had a theory that maybe there was still something out there like DNS that wasn't updated, and was being used before the hosts file (hence looking at nsswitch.conf). It was a long shot. A really long shot. (Unless maybe there was something in that cache Bill had you delete, but I have zero idea what's in there).

Anyway, probably doesn't matter now, it looks like you've gotten past that part.

@bill6502, pretty sure Slackware uses init.

[rocknrobin72]

bill6502...I forgot to add from your previous reply when you advised to set up the additional logging by first :

Code: Select all

sudo systemctl stop mythtv-backend.service (or whatever you use)

Slackware does not use systemctl to stop/start services for applications. The only thing I know of to see if the mythbackend is running is

Code: Select all

ps -ef | grep mythbackend

The response to that command will be the line used to start it:

/usr/local/bin/mythbackend -d --setloglevel debug --logpath /var/log/mythtv

I do not start mythbackend at boot time either, I just manually start it with the above command after the boot process completes and I log in. As shown by the log for the normal start the last line is exiting which means nothing about the backend started, or at least that's what I thought. I don't believe any service is started because it bombs off.

if the backend is running. At that point to stop the backend I use, or did use the killall mythbackend command. Slackware starts and stops daemons by issuing commands from the /etc/rc.d directory, i.e. /etc/rc.d/rc.httpd (start, stop, or restart) so I wasn't able to run the systemctl command to stop the mythtv-backend.service nor do I believe there is a mythtv-backend.service file...or at least I have not been able to find it.

Is there another way I can set up this verbose logging? I can create the /etc/mythtv/additional.args, but I would only know to put the one line you mention in it and there is no /etc/mythtv/ direcotry presently. In addition with no mythtv-backend.service file I can't update it either.

[rocknrobin72]

Uncle Bob...In response to your question about the IP address changing...I actually have three hard drives, two PCs, running Slackware and mythtv that I maintain. The 10.x.x.69 address is my original Slack server and unfortunately I had the terminal windows open for .60 and .69 when I started sending screen shots from the failures and I inadvertently must have grabbed the output from the .69 box in my first post(s). I normally will make sure the updates work, and/or don't break anything, on the .69 box before I update my other two Slack boxes. Unfortunately I got in a hurry this time and updated all of them before I tried mythtv and unfortunately it was too late by the time I checked mythtv. I apologize for the confusion.

[bill6502]

OK, just use the same command line as before, but spin it off. You can kill it as you normally do.

Code: Select all

sudo mythbackend --user=mythtv --verbose=most,norefcount --loglevel=debug --logpath=/tmp --quiet &

[rocknrobin72]

bill6502...I have posted another output from the log in the same place as before. I let it run and run for about 20 to 25 minutes and it still didn't fail. I can try it again if you like, but it seemed like it just kept repeating itself, but didn't every fail on its own.

I even tried connecting my Kodi frontend to it while it was running; it connected, loaded the guide, and would also play one of the recorded shows.

Why is it that it will run in this verbose/debug mode and not fail when it won't start running with the normal command I have been using in the past to start it? Thanks.

[rocknrobin72]

Another comment I have is that prior to the updates which broke Mythtv when I started mythbackend I would go to /var/log/mythtv, find the running backend log and run tail -f ......log on the log to monitor the progress of it starting. By the time I could run the tail -f command the log would be up to 10k or so and I caught it at

Code: Select all

2023-05-02 21:50:34.653202 I [28935/29052] Scheduler scheduler.cpp:2510 (HandleRunSchedulerStartup) - Scheduler: Seem to be woken up by USER

When it stopped working by the time I could get to the log file to tail -f it it would only be up to 3800 to 4k size and hung on the en_us translations until it finally bombed off a few seconds later. I didn't know if describing this behavior would be any help or not.

[bill6502]

I'd start by removing options from the command line that works. How 'bout just these for 1st: -verbose=most,norefcount --loglevel=debug
Watch the log in /tmp again. If it works, restore the --logpath to the previous /var/log/mythtv and look at it there.