[mythtv-users] mythtv dropping mysql???

[Thomas Mashos]

On Wed, Oct 22, 2014 at 11:10 AM, Rich Freeman
<r-mythtv at thefreemanclan.net> wrote:
> On Wed, Oct 22, 2014 at 12:46 PM, Michael T. Dean
> <mtdean at thirdcontact.com> wrote:
>> On 10/22/2014 11:09 AM, jedi wrote:
>>>
>>>      As far as the "appliance" thing goes, one of my own examples of "db
>>> tinkering"
>>> is a script that clones settings from one machine to another. This
>>> simplifies the
>>> task of setting up a new frontend considerably. All of the media storage
>>> definitions
>>> get cloned as well as a basic set of UI related settings. Since I use
>>> roughly
>>> standardized hardware for the frontends (ION), I also clone the decoder
>>> profiles.
>>
>>
>> This is not an example of something that requires direct DB access using
>> non-MythTV tools.  This is an example of something that MythTV should allow
>> all users to do easily from within the UI.  This is an example of something
>> that hasn't been done because it's easy enough for devs or power users ***
>> to do without creating a proper UI.  This is an example of a feature MythTV
>> is lacking *because* the mysql-direct-database-access tools are a crutch
>> we've been leaning on.
>
> Sure, but there are lots of other use cases as well.
>
> How about this one, run hourly from crontab:
> UPDATE \`recorded\`  SET \`autoexpire\` = '1',
>  \`preserve\` = '0' WHERE \`seriesid\` IN ('<bunch of ids>') ;
>
> Do you REALLY want to create a UI for that?  Maybe have setting in the
> recording rules that controls not only # of episodes to save and
> autoexpire but also whether those flags can be toggled per-recording,
> with role-based access control to who can edit the recording rule?  I
> don't want to dump that on the devs.
>
> Or (also run hourly):
> UPDATE \`recorded\`  SET \`autoexpire\` = '0',
>  \`preserve\` = '1' WHERE \`autoexpire\` = \`preserve\` ;
>
> That saves me having to toggle two flags at a time in the UI.  If we
> want to have another button that switches them together I'm fine with
> that.
>
> Another one I was running in the past was dealing with failed jobs,
> but that is something that should be part of the application.
>
> Channel manipulation is another case where I tend to use SQL.
>
> I don't expect the developers to cater to every one of my little
> needs.  That's just one of the benefits of having the data in a
> database - they don't have to.  I do realize that some of this might
> be doable via scripting, but unless the script just runs raw SQL on
> the database you're not going to get the same performance out of it
> and it is another "language" to learn.  If it does run raw SQL on the
> database, then there is no way to control it and you get all the
> downsides of allowing outside database access today.
>
> For me though it is as much about just having access to the data and
> knowing it is someplace I can get to and repair if there is a problem.
> It is as much a control thing as anything else.  I realize that if I
> break it I get to keep the pieces.
>
> --
> Rich
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

Completely separate from the topic, I've got to ask. Why are you guys
doing so much work on your MythTV install? What I mean is, what are
you accomplishing with this? Please keep in mind, I'm not asking "why
are you doing SQL queries to accomplish this" as I will fully agree
that is much quicker via SQL commands. Please also note I'm not asking
what" 'UPDATE \`recorded\`  SET \`autoexpire\` = '0', \`preserve\` =
'1' WHERE \`autoexpire\` = \`preserve\` ;" does (or similar SQL
queries), as I can read from the query what it is doing. I'm asking
what you are accomplishing by doing this? What is the problem you are
trying to fix.

I ask, because the only time I've ever had to directly alter my mythtv
DB, it was because there wasn't a way to set the live tv timeout
anywhere else (eg. a long time ago).

-- 
Thanks,

Thomas Mashos