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

Lawrence Rust lvr at softsystem.co.uk
Thu May 3 19:02:00 UTC 2012


On Thu, 2012-05-03 at 11:24 -0400, Daniel Kristjansson wrote:
> I've attached the latest patchset to the ticket. I just wanted to
> give everyone a heads up in case they had strong opinions on the
> config.xml format or want to look at the UPnP backend discovery
> changes.
> 
> Summary of changes:
> * Format of config.xml
>  + Database settings have their own top-level instead of being under
>    <MythFrontend><DefaultBackend>.
>  + Wake On Lan settings have been added to config.xml, these
>    were formerly only settable using mysql.txt.
The parsing of xml files is just a total waste of CPU resources.  They
add no useful information c.f. a well constructed ini file,

> * UPnP autoconf now waits a full 2 seconds before deciding there
>   really is only one backend to connect to.
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?

> * 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.

>  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.

> I'll commit tomorrow if there are no objections.
++objections

-- 
Lawrence


More information about the mythtv-dev mailing list