[mythtv-users] mythtv dropping mysql???

[Rich Freeman]

On Tue, Oct 21, 2014 at 9:19 AM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 10/21/2014 02:47 AM, Michael Watson wrote:
>>
>> Is it that, it has come a time that MythTV needs a consistent DB engine,
>> much like the need for a consistent ffmpeg version.  Are the differences in
>> DB engines becoming to great across distros/platforms?
>
>
> That's not really a concern at this point.  We only support "MySQL" (which
> includes--at least until there are significant differences--at least some
> MariaDB allowance) and we don't need any modifications to the MySQL code and
> only need to enforce a minimum DB version.

So, why not just specify a minimum DB version, or even a standard
configuration?

Today if I want to change the preserved flag on 100 recordings for a
particular episode, that is one line of SQL, vs writing some script in
a language I might not prefer using an API I'm not familiar with to
iterate over all the recordings in the database just to filter on one
and modify another.  MySQL can run that UPDATE query in milliseconds
without having to do a table scan, and in a way that doesn't need
table locks and such.  I doubt the same is going to be true of a
script.

Honestly, half the problems I've had with MythTV over the years (which
aren't many) come from the fact that it embeds its own ffmpeg, etc.
It makes transcoding programs painful since the player tends to be
very finicky about file formats (fixed interval keyframes, etc).  And
I say that as somebody who was burned by the UTF8 issue - fixing that
only took an hour or two, and I've never managed to get transcoding on
mythtv to work the way I want to.  But, hey, I'm not paying so I'm not
going to gripe about it - it just strikes me as a design limitation to
be so wedded to particular formats because the software is treated as
a closed ecosystem.  Xine or mplayer or vlc can handle just about any
file you throw at them - why re-invent the wheel?

For me a huge reason I switched over to MythTV was that it was so
open.  My recordings are just mpg files.  Even the nuv files might be
obscure but they can be read with open tools.  My data is in a
database that is very popular and has a large library of software
supporting it.  I never lose data as a result, but if for some reason
the front-end decided to chew up my data I can just pull up my latest
backups and recover easily.

Maybe I store mysql data on ext3 to avoid ext4 performance issues
(without putting all the other data on my filesystem at risk), which
is easy when it is standalone, but hard when mythtv wants to control
where all the files go, etc.  Maybe I don't want mysql to use half the
RAM on my box which has 47 other things running on it, even if that
compromises the mythtv experience, etc.

By all means provide standard configs, or recommended settings.  By
all means specify a required version of mysql or ffmpeg or whatever.
However, please do not fork mysql and embed it into mythtv.  If
anything I'd prefer if mythtv moved to using upstream versions of
ffmpeg or libav (and by all means specify which versions are
acceptable).

If a user just wants an all-in-one mythtv box then they should just
use a distro like mythbuntu, where the integration has been done at
all layers of the OS.  MythTV shouldn't be merging mysql, lirc,
pulseaudio, and various other projects into its code in an effort to
control the whole experience.  I personally found getting lirc working
to be far more annoying than creating another mysql database on my
mysql server.

I do appreciate that I haven't paid a dime for MythTV, so I'm grateful
for whatever I can get, but as a user I just don't think that this is
going to be a change for the better.  I realize that supporting
exactly one detailed configuration can make life easier on the
developers.  However, in my experience it tends to cause problems for
anybody who wants to do things in exactly the way the developer
intended them to be done.

--
Rich