[mythtv-users] mythtv dropping mysql???

[Rich Freeman]

On Wed, Oct 22, 2014 at 8:51 AM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> I suppose we can put up a sign on the home page that says, "Must be this
> tall to enter" with a picture of you and a line at your head level.
> Obviously, anyone who isn't as smart as you isn't good enough to run MythTV?

People who don't understand this stuff shouldn't be downloading a
source tarball of MythTV from the website, compiling it, and
installing it.

If they're getting MythTV from a distro, then it is the distro's
problem to deal with this stuff.  I maintain this stuff on Gentoo, and
I doubt that any of my users are going to run into these kinds of
problems, though in part that does reflect some selection bias.  :)
I'd imagine that if somebody was maintaining a bulletproof MythTV
distro that they'd account for these sorts of issues.  Distros that
aim to be bulletproof but don't want to take on the work of making
bulletproof tend not to package MythTV (for example, I don't think
Ubuntu does).

> You do realize that "embed" doesn't mean, "Put a copy of the MySQL code into
> MythTV," right?  It simply means, "Use a database that doesn't require
> running an external database server application."

You embed ffmpeg today by putting a copy of the code into MythTV, and
you talk about having control over what features the database
supports.  That sounds like doing a cp -r on some portion of mysql and
sticking it in MythTV.  Or do you want to deal with the bug reports
when you go to create a table with a particular storage engine and the
MySQL installation on the user's system doesn't support that storage
engine?  And I don't suppose you're going to make that configurable in
case I don't like your choice of storage engine or the configuration
of the memory caching, right?

If you are going to use embedded MySQL I'd definitely prefer that you
use the system installation of MySQL, but it seems like your
motivation is going to tend to lead to this not being the case.

>
> Then again, maybe you don't want MythTV to fix things and you'd prefer that
> after the power outage the day you left, nothing gets recorded for 3 weeks,
> so that when you get back you would know about the unclean shutdown.

Great, so is the next step to integrate btrfs check into MythTV, just
in case the recordings directory won't mount cleanly?  Hmm, maybe the
version of btrfs-progs you merge in won't work with the kernel
supplied with the distro - might not hurt to embed linux and systemd
while you're at it.  :)

I get what you're trying to do, but this seems like one of those
situations where a partial solution gives up a lot but gains very
little.  If you were going to build a MythTV distro that allowed you
to stick a CD in the drive, multi-select frontend/backend/database
from the list, and then auto-configure with discovery across the
network I'd say more power to you.  That would be an appliance.  I
might even switch to it and run it in a VM or something (though I'd
really like it if you supported running as a container), and bonus
points if you support PXE front-ends with NFS roots.

KDE uses embedded mysql, but it supports using the system version of
it, and it also supports storage in an external database.  They seem
to be able to do it without an endless series of bug reports.  (Not
that I'm holding up akodami as something I'd love to see you emulate.
:) )

I'm all for finding ways to make MythTV easier to package up as an
appliance-like solution.  I just don't think this is quite the way to
go about it.  I bought a router that runs DD-WRT, and it was easy to
use out-of-the-box but if I want to I can start openssh on the thing
and do VLAN.  The average home user will just plug it in and hit the
WPS button.  There is no reason that we can't offer the same kind of
experience with MythTV.  I wouldn't do it by slowly merging 3rd-party
code into the MythTV application.  I'd do it by controlling the whole
experience - start with something like Mythbuntu and go from there.
Have a recommended hardware list.  Design the thing so that you can
just grab 5 PCs, run the CD on each, and end up with a system that
forms a cohesive unit, and lets you PXE boot front-ends from them.
Heck, with PXE you can just enable it in a Windows PC and boot any PC
on the LAN as a temporary front-end (while still offering DLNA/etc for
use in Windows/etc).

There are lots of ways of going about this, but this strikes me as
being something that will take effort, alienate power users, and not
really result in anything easier for somebody who wants a Tivo-like
experience.

--
Rich