[mythtv-users] mythtv dropping mysql???

[Rich Freeman]

On Tue, Oct 21, 2014 at 1:03 PM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 10/21/2014 11:14 AM, Rich Freeman wrote:
>>
>> On Tue, Oct 21, 2014 at 9:19 AM, Michael T. Dean 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.
>
>
> The point is you shouldn't have to write /any/ script--nor even leave the
> MythTV-provided UI's to do this.

You really don't want to create a UI for half the stuff I do in SQL.
Trust me.  :)

Some of the stuff I do in SQL is specifically designed to undo stuff
done via the UI.  The MythTV UI isn't always family-friendly and I
doubt you want to create role-base access control tuneable per-user,
per-function, per-show.

>
> Well, obviously you haven't looked at the PHP bindings, nor have you looked
> at the types of things that are available through the backend web server--as
> a matter of fact, it seems you don't even know what's available in MythWeb.

I don't want to look at MythWeb once an hour to make changes to the
database when cron can take care of that more efficiently.

I certainly haven't looked at the PHP bindings, because there is no
need to do so and it would take a LOT more effort to maintain that
then a two-line SQL script.


>
> You do realize that xine and mplayer both have their own "embedded" versions
> of ffmpeg libraries, too, right?  VLC may not, but then again, AIUI, ffmpeg
> is actually owned/maintained by VLC developers so they write their code for
> the ffmpeg they create.

I didn't realize that.  It is probably because my distro disables it
and forces it to link to the system version of the library in both
cases.  I imagine that most distros do the same.  If you want an even
bigger example of bundling just look at just about anything published
by Google for Linux.  Heck, I think at one point they had a "Linux"
build of Google earth that bundled Wine and the Windows version of
Google Earth.

66% of the chromium browser tarball is composed of redistributed
3rd-party code that everybody gets to try to strip out of the build
system.  Distros do in fact go to the trouble of doing this.

And do we need to bring up zlib?  :)

>
> And nothing will change there.  Actually, it will.  MythTV will
> automatically make database backups for users--at a time when no
> applications are using the MythTV database.

If you want to create an easy-to-use mechanism that can be used to get
a hold of the database while MythTV isn't using it for backups I'm all
ears, but you don't have to fork the database server to do it.

>
>>    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.
>
>
> Well, since you won't have to run MySQL, that's not a problem.

You're talking about embedding mysql.  You might rename it, but you're
still running it.  The RAM it uses won't magically go away because its
functions are running in a process under another name.  It will be
just that much harder for anybody to change how it behaves.

>
>> 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.
>
>
> Um, there's no forking involved.  MySQL Embedded is a product--and an open
> source one at that.  We'll just switch to using that product.  Specifically,
> we'll use libmysqld.

Then why not use the one supplied by a distro, and not bundle your
own?  Better still, just make it one option among many.

>
>>    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).
>
>
> We'll do like MPlayer and xine, OK?  :)  (That said, TTBOMK, we're closer to
> using plain vanilla ffmpeg, now, than those other projects are thanks to
> some work JYA did.)

Well, my mplayer and xine absolutely use vanilla ffmpeg since that is
what they're linked against.  If they break I bug my distro about it.
Worst case I'll be told I should probably be using libav anyway.  :)

>
> I don't see why people think this is going to be a huge change.  About the
> only things that are changing are a) you won't have to run mysqld and b) you
> won't be able to just connect directly to the database with mysql
> command-line client (at least not while MythTV is using that database).

Obviously b is more concerning than a.  MySQL works fine - I don't
need it to change.

> You'll still be able to access and modify your data--you'll just be able to
> do it more easily and better than you can now.

Uh, sure.  Right now I can change just about anything at will in the
database.  Having to halt mythtv (aborting any recordings
in-progress), then mess around with mysql tools absent a server
doesn't really sound like an improvement.

But, if you REALLY are committed to using mysql embedded without any
changes it will just make it that much easier to fork...

--
Rich