setup failing to find database on new install

[Craig Treleaven <ctreleaven@…>]

Installing in Mac VM, with no config.xml set up, launching mythtv-setup is not prompting for database info but is failing after attempting to use a link local address

Logs at ​https://paste.macports.org/ff725cb3c686 ​https://paste.macports.org/3814495f8835 ​https://paste.macports.org/82dbbeb7eb5e

[Peter Bennett]

These lines in the log reveal the problem. It found a backend via UPNP and then tried to use the link-local address for SOAP, which does not work.

2017-08-04 09:42:26.640058 I [3622/3335] CoreContext mythcontext.cpp:1160 (UPnPautoconf) - Found 1 UPnP backends
2017-08-04 09:42:34.842184 E [3622/3335] CoreContext mythdownloadmanager.cpp:1045 (downloadNowLinkLocal) - DownloadManager: Link Local request failed: http://[fe80::3c5c:e6ff:feb7:d194]:6544/Myth
2017-08-04 09:42:34.842339 E [3622/3335] CoreContext soapclient.cpp:253 (SendSOAPRequest) - SOAPClient::SendSOAPRequest: request failed: http://[fe80::3c5c:e6ff:feb7:d194]:6544/Myth

I tried to reproduce it on Linux, but I cannot. If I have a backend running it retrieves the address successfully and connects.

This should not happen anyway. If your backend is running it means your setup has been done, so you should have a config.xml available to mythtv-setup.

Your problem should be resolved if you make sure there is no backend running when doing setup for the first time. In that case the setup prompts for your database settings and then proceeds normally.

It may have found another backend on another server that is not relevant to what you are doing. If you have multiple backends going this kind of thing can also be avoided by setting a PIN on your backends (i.e. on that other server, in mythtv-setup, General, Host address backend Setup, set a PIN other than 0000).

[ctreleaven@…]

Just to confirm, my 'production' 0.28 backend is/was running on another machine. I was using the VM for an initial test of v29. In my defence, I've done the same when 0.28 and 0.27 were new without having a similar issue. In fact, I'll do similar when creating/testing my all-in-one installer for 29. I use a virgin VM to test the deployment of Myth. I guess I'll have to explore the PIN codes because it just isn't feasible to take down my production machine that often.

If the code is working as designed, would it be possible to at least provide a log message that identifies the real issue?

Also, based on your suggestion on IRC, I created a config.xml and then was able to proceed.

[Peter Bennett]

The UPNP discovery is what allows a new frontend that has been setup without a .mythtv directory, to find and connect to the database and backend, and create the .mythtv directory.

When 0.28 was new, it had a bug where the UPNP discovery was not working, so you would not have hit this problem, but you would have been forced to create config.xml for each frontend. It is possible that it was also not working when 0.27 was new.

If you are running more than 1 master backend I think it is imperative to setup a pin on each backend so that new frontends or other programs do not connect to the wrong system if they have no config.xml.

I will keep this ticket open and look to see if there is some improvement that can be made.

[Peter Bennett]

Setup should not attempt to contact a backend for database info. I plan to implement a fix to prevent that. Also other programs may benefit from the same restriction that they should not search for a backend.

[Peter Bennett]

This patch prevents setup from searching for a backend, and causes it to go directly to database settings if config.xml is not set up.

[Peter Bennett]

Patch to prevent autodetect in mythtv-setup

[Peter Bennett <pbennett@…>]

In 01a3b5f11b0064c3af2bceda1cf55fa0add5072a/mythtv:

Fixes #13090 - Prevent mythtv-setup from searching for a backend via upnp

[Peter Bennett <pbennett@…>]

In ea16cdc33a593ec90ec37cf7cb1488a6e1106e25/mythtv:

Fixes #13090 - Prevent mythtv-setup from searching for a backend via upnp

(cherry picked from commit 01a3b5f11b0064c3af2bceda1cf55fa0add5072a)