Improved Frontend Startup in case of connection problems

[Peter Bennett]

When starting up the MythTV frontend, if the database is unavailable, the user gets the Country and Language selection page, even if they have previously completed setup. This is confusing to the newcomer and annoying to the experienced user. If the user continues with selecting Country and Language it does not resolve things and leads one down a rat hole.

If the user has set up database WOL, the experience is also not good. There is no feedback while the database is starting up. Nothing is displayed, and it looks as if nothing is happening for however long it takes for the database wakeup.

I plan to add a new MythTV startup page that will be displayed if the database and backend are not immediately available, and if setup was previously done (i.e. config.xml is available). It will wait a reasonable time for the database and for the backend, while showing user messages as to what is happening. After some time if the database and backend are not available it will provide buttons to "Retry", "Setup", or "Exit". Selecting Setup will continue to Database setup so that the user can correct his settings if necessary.

[Stuart Auchterlonie]

I am thinking of adding DBus based support to verify that the relevant network interfaces are up.

This would help the case when the OS is on SSD and the frontend is started at boot times, this often results in the network not being up when the frontend starts up, and you end up in the situation you are describing.

[Peter Bennett]

The ping in the database connect startup has been causing some people problems lately, and I think I can improve startup by checking if the database port is open instead of using ping. That way it waits for not only the database machine to start up but for the database port to be ready. Also people could use the "wake up" code to start the database instead of waking the machine (if somebody for some reason wanted the database shutdown when MythTV was not in use).

I have been doing this (using nc) in a bash script in front of Frontend startup for a couple of years with no problems.

[sphery]

Regarding DB ping (whether using mysqladmin -ping, mysql_ping, or homegrown code), please see [5b3aaea9] and the thread at ​https://lists.gt.net/mythtv/dev/284304 (especially ​https://lists.gt.net/mythtv/dev/284318#284318 and ​https://lists.gt.net/mythtv/dev/284319#284319 ). The current approach, pinging the host, while not perfect (since it doesn't detect the DB itself), was meant to be fast--especially when the user misconfigures things. Making a user wait 3min at initial setup only to be told the database couldn't be contacted would make initial setup even more frustrating. Also, many first-time users tend to put the MythTV backend port into the MySQL port box, so any test you do needs to be sure to not crash (or cause problems--client or server side) when it hits a non-MySQL port.

That said, once initial (interactive) configuration is done, I'm a big fan of the just-do-it approach (i.e. don't check to make sure things still work--instead just do what we're told and fail/shut down if it doesn't work). That said, in this world of systemd and "shotgun start everything, assuming order is irrelevant", I seem to be one of the few who's willing to consider a proper system configuration and working prerequisites as a startup requirement. (In other words, I don't mind if things change, but wanted to mention the how we got to where we are backstory.)

[Peter Bennett]

Replying to mdean:

Also, many first-time users tend to put the MythTV backend port into the MySQL port box, so any test you do needs to be sure to not crash (or cause problems--client or server side) when it hits a non-MySQL port.

This is a problematic one. If you put the backend port 6543 as the database port with the current MythTV the frontend startup just hangs forever, with no GUI displayed. It is stuck in some receive logic inside the SQL driver trying to open the database. I am not sure the best way to fix that. There does not appear to be any timeout ability in the MYSQL connect.

I looked at the other links. the code in [5b3aaea9] has been considerably changed since it was added, and I am completely revamping it now. The mailing list links with topics around the ping will be completely solved, since will be checking a specific port with a QT Socket instead of doing a ping.

I am making some good progress. Opening a socket of the expected port, with a short timeout in case of failure, seems to be giving good results and I have a frontend page with a progress bar showing what it is doing as far as waiting to database to wake up, waiting for database to start, waiting for backend to wake up, etc.