0.29 backend crashes

[PhilB]

I'd appreciate any words of wisdom here.
I have set up xbuntu 18.04 on a test disk and installed Mythtv 0.29 combined FE and BE. My tuners are Hauppauge T500 (dual) and a Hauppauge USB stick, both DVB-T. The hardware runs Mythbuntu 14.04 reliably.

I had problems with nvidia 8300 graphics but think I've sorted that - at least the screen isn't jumping all over the shop now and I'll update my other
posting once I get some real video out.

I can run backend setup and have scanned and picked up my DVB-T stations but the backend keeps failing.

The full backend log is here: https://pastebin.com/4YevDrXR

The tail of it is:

Jul 21 15:12:02 myth mythbackend: mythbackend[1468]: I CoreContext mythcontext.cpp:607 (LoadDatabaseSettings) Using localhost value of myth
Jul 21 15:12:02 myth mythbackend: mythbackend[1468]: I CoreContext mythcontext.cpp:852 (TestDBconnection) Start up testing connections. DB localhost, BE , attempt 0, status dbAwake
Jul 21 15:12:02 myth mythbackend: mythbackend[1468]: I LogForward loggingserver.cpp:302 (SyslogLogger) Added syslogging
Jul 21 15:12:03 myth mythbackend: mythbackend[1468]: N CoreContext mythcorecontext.cpp:1768 (InitLocale) Setting QT default locale to en_GB
Jul 21 15:12:03 myth mythbackend: mythbackend[1468]: I CoreContext mythcorecontext.cpp:1801 (SaveLocaleDefaults) Current locale en_GB
Jul 21 15:12:03 myth mythbackend: mythbackend[1468]: N CoreContext mythlocale.cpp:123 (LoadDefaultsFromXML) Reading locale defaults from /usr/share/mythtv//locales/en_gb.xml
Jul 21 15:12:03 myth mythbackend: mythbackend[1468]: I CoreContext mythtranslation.cpp:73 (load) Loading en_gb translation for module mythfrontend
Jul 21 15:12:03 myth mythbackend: mythbackend[1468]: I CoreContext schemawizard.cpp:120 (Compare) Current MythTV Schema Version (DBSchemaVer): 1348
Jul 21 15:12:03 myth mythbackend: mythbackend[1468]: I CoreContext mythtranslation.cpp:73 (load) Loading en_gb translation for module mythfrontend
Jul 21 15:12:03 myth mythbackend: mythbackend[1468]: E CoreContext mythsocket.cpp:414 (ConnectToHost) MythSocket(5567f0c75a90:-1): Unable to lookup:

Systemctl status is this:

>systemctl status mythtv-backend.service
mythtv-backend.service - MythTV Backend
Loaded: loaded (/lib/systemd/system/mythtv-backend.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2018-07-23 16:51:25 BST; 5min ago
Docs: https://www.mythtv.org/wiki/Mythbackend
Main PID: 15869 (code=exited, status=138)

Jul 23 16:51:24 myth systemd[1]: mythtv-backend.service: Failed with result 'exit-code'.
Jul 23 16:51:25 myth systemd[1]: mythtv-backend.service: Service hold-off time over, scheduling restart.
Jul 23 16:51:25 myth systemd[1]: mythtv-backend.service: Scheduled restart job, restart counter is at 22.
Jul 23 16:51:25 myth systemd[1]: Stopped MythTV Backend.
Jul 23 16:51:25 myth systemd[1]: mythtv-backend.service: Start request repeated too quickly.
Jul 23 16:51:25 myth systemd[1]: mythtv-backend.service: Failed with result 'exit-code'.
Jul 23 16:51:25 myth systemd[1]: Failed to start MythTV Backend.
Jul 23 16:52:27 myth systemd[1]: mythtv-backend.service: Start request repeated too quickly.
Jul 23 16:52:27 myth systemd[1]: mythtv-backend.service: Failed with result 'exit-code'.
Jul 23 16:52:27 myth systemd[1]: Failed to start MythTV Backend.

Restarting the backend does not fix it so it does not initially look like a timing problem. That 'too quickly' message even occurs immediately after a reboot. Can anyone tell me which socket is failing and what might cause it please? Alternatively, how do I get more verbose diagnostics?

Thanks
Phil

[bill6502]

Hey Phil,

What does this return:

Code: Select all

SELECT * FROM settings WHERE value IN ('MasterServerName', 'MasterServerIP', 'BackendServerIP', 'BackendServerIP6');

[PhilB]

Hi Bill,
thanks for your reply. That curl gives 'failed to connect to localhost 6544: connection refused. Wouldn't that be expected because backend isn't running?

hostname returns myth (as expected)

ping localhost works, as does 'ping 192.168.x.y' from both the myth and another system.

I think I was premature over that Nvidia driver - the system has just switched spontaneously to Nouveau drivers! We are having fun!

Phil

[bill6502]

Oops, guess if the backend isn't running the API won't work very well. I edited
the above to use SQL.

I haven't seen a segfault from a blank MasterServerName, but have seen
other issues. Haven't been able to find the actual cause of the problem.
Just want to be sure the DB upgrade to 1348 worked as it should and
populated the host (as it looks from the logs that it didn't.)

[PhilB]

Hi Bill,
as I think you suspected, that showed 'empty set'.
However, the system started complaining that the root partition was read-only and on reboot was corrupt.
I think this backend issue will have to take a back seat until I've resolved the filestore issue.
Thanks
Phil

[PhilB]

Hi Bill,
I'm going to tentatively mark this as solved. Backend sprang to life after I changed IP address from 127.0.0.1 to the DHCP allocated one of 196.168.x.y and the log showed it updating schemas. Now all I need is a stable xubuntu.
Many thanks for the pointers.
Phil