[mythtv-users] mythtv dropping mysql???

[Michael T. Dean]

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.  That's a task which *should* be 
easy to accomplish with MythTV, but is now a real pain in the neck 
(which is why you use a hackish approach that requires you to leave the 
MythTV UI, go to a terminal (web browser), run mysql command-line client 
(phpmyadmin), and submit SQL (a language which some are not familiar 
with) to select certain recordings from the database (being careful not 
to select ones that shouldn't be included) and modify a field by writing 
a value that you believe is the one MythTV expects you to use).

Currently, to do something like this in MythTV, you would have to take 
one of a couple approaches.  If all the recordings you wanted to modify 
are in the same title or recording group or other "left-hand column" 
category of the Watch Recordings screen, you go to that category and 
select MENU|Add this Group to Playlist, then MENU|Playlist 
Options|Storage Options|Disable Auto Expire.  If the recordings aren't 
all part of the same left-hand column group, then you have to find each 
recording and MENU|Add to Playlist (for 100 recordings), and then use 
the MENU|Playlist Options|... approach.  However, preserving an episode 
is an option that's available in the single-recording Storage Menu 
(MENU|Storage Options|Preserve this episode), but isn't available in the 
Playlist Options|Storage Options menu, so the only approach available in 
MythTV's UIs (TTBOMK, there's no way to set preserve using MythWeb) is 
to find each recording, individually, in Watch Recordings and use 
MENU|Storage Options|Preserve this episode)--which is hard enough work 
when using a remote to do even once due to the sheer number of button 
presses required.

*That* is the problem.  The solution isn't to allow users to use a tool 
that has nothing whatsoever to do with a DVR (mysql command-line client) 
to poke data directly in the database (hoping that changing data out 
from under running MythTV instances won't cause problems), but to 
actually create a UI that allows users to do what users need to do.

I have looked all over the my Brighthouse DVR and I can't find any way 
at all to start up a mysql command-line client on it, so it seems that 
mysql command-line client/SQL isn't the best solution.

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

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.

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

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.

http://xine.cvs.sourceforge.net/viewvc/xine/xine-lib/src/libffmpeg/
and see the ffmpeg directory of the MPlayer source package (I have no 
idea where--or even if they have--the public repo viewer for MPlayer exists)
and
http://git.videolan.org/?p=vlc.git;a=summary
http://git.videolan.org/?p=ffmpeg.git;a=summary

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

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.

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

Who said MythTV will control where all the files go?  Do we control 
where your recordings go?  Nothing is different about the database.  
You'll specify where the data should be stored.

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

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

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

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

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

Anyway, I'm done trying to explain.  As Paul said, it's not worth the 
time it's taking.

Mike