[mythtv-users] mythtv dropping mysql???

Tue Oct 21 19:21:12 UTC 2014

On Tue, Oct 21, 2014 at 10:57 AM, Rich Freeman
<r-mythtv at thefreemanclan.net> wrote:
> 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...

I'm sorry, but I just had to respond to this.

No, it doesn't make MythTV that much easier to fork. Forking is not
simple, threatening to fork is. If you have enough knowledge about
MythTV to fork it, why don't you just contribute back to the main
project? People with much more knowledge of MythTV have forked it
before, please ask them how well that went for them ( see torcdvr.com
)

>
> --
> Rich

-- 
Thanks,

Thomas Mashos