[mythtv] #10305 heads up, mysql.txt removal + config.xml changes + UPnP fixes

[danielk]

On 05/03/2012 03:02 PM, Lawrence Rust wrote:
> This is far too long to sit idle. Any reasonable local UPnP server 
> will respond to a broad/multicast request within a few milliseconds. 
> What are you waiting for a Sinclair ZX80? 

This only happens when run without a config.xml and without the
--prompt command line option. Without changes to our UPnP implementation
the choices are 1 second, 2 seconds or more. With one second we do not
have an opportunity to resend the multicast request so if that packet is
lost. Two seconds is the minimum value we can use if with resends.
Larger values would allow a better chance of a response.

>> * UPnP resends the discovery packet a few times in auto conf mode.
>> * config.xml is only rewritten when it changes, and this is done
>>    in a safe manner so a crash will not wipe out your configuration.
>> * mysql.txt reading has been removed. This does not port over
>>    Wake On Lan settings and all other settings not written to the
>>    file by default are ignored.
> There are many 3rd party scripts that rely on mysql.txt.  It can contain
> the same information as config.xml and takes just a fraction of the CPU
> resources to parse.  Why not settle for this file alone?  Or, what about
> a halfway house - a config utility that takes simple command line
> queries and returns simple text strings.
This is one of the reasons I didn't apply this patch before the 0.25 
release.
But config.xml vs mysql.txt isn't up for debate. While I like the simplicity
of mysql.txt, it's more important that we have one initial config file than
the particular format of that file. Which one was a question a few releases
back and the overwhelming preference was for the xml format. The heads up
was in case someone wanted to look at the code and wanted to comment on the
particulars of the xml format or other details.

>>   Setting file functionality is
>>    available using the --override-settings-file option, which
>>    has the added benefit of overriding DB settings instead of just
>>    providing new defaults if the DB doesn't have that setting.
> This is just a recipe for disaster with some db values coming from a
> user provided file that could conflict with settings in the main
> database.  This resolution should be handled by a common parser within a
> myth library.  Another good reason for a config utility.
This isn't a new feature. There were three ways to set settings outside
the DB, after this change there are now two.

-- Daniel