[mythtv-users] Converting scripts to not use the database directly

Michael T. Dean mtdean at thirdcontact.com
Tue Nov 4 14:53:27 UTC 2014


On 11/04/2014 09:19 AM, Simon Hobson wrote:
> Michael T. Dean wrote:
>
>>> My observation was that we are taking a step back from being able to use a tool where all the looping is nicely handled for us. Instead, everyone who writes a script to operate with the API would, it appears, have to re-invent the wheel every time.
>> So it's that much harder to do:
>>
>> chanids = [1031, 1081, 1161, 1281, 1282, 1283, 1384]
>> for channel in Channel.GetChannelList(chanids)
>>     channel.SetVisible(false)
>>
>> than
>>
>> UPDATE channel SET visible = 0 WHERE chanid in (1031, 1081, 1161, 1281, 1282, 1283, 1384);
> Just the same way that pretty well everything that can be done with AWK can also be done in shell - it's just that AWK is often the superior tool for the job. The parallel being that AWK is great for "looping over stuff" and automatically handles the looping in the background - instead of writing the loops in shell as can also be done.
>
> In any case, are you over simplifying the update to make it look "not as bad". Does the API have a fully flexible selection ability ? Ie, is "get a list of channels where<some arbitrary criteria>" doable directly with one call, or do we need to get a list of channels, iterate through them to select the ones to work on, and ONLY THEN do the simple bit you've written ?
>
> BTW - is doing an update really just "channel.SetVisible(false)" or is there more to it than that ?

That is the plan--simple to select with some arbitrary combination of 
criteria and simple method calls to change one or more values of the 
object.  Much of it is already available, though it will become even 
easier (for example, as more of the Services API becomes 
available/useful and as the Python bindings start wrapping the services 
API to make an easy-to-use API).

>>> I understand the desire to remove direct access ot the DB, but to remove a "good" tool (from the user's perspective) and replace it with what appears at the moment to be very inferior does seem a step backwards. IMO to be a "good" replacement the API needs to support set operations, arbitrary joins, arbitrary selections, and relative updates - which makes it sound rather like SQL ! It looks very much like at least 1 or 2 of those are missing.
>> You make an interesting point.  I'll work on removing some of the inferior tools we have right away.
>>
>> In Watch Recordings, we currently have MENU|Playlist Options|Storage Options|Change Recording Group, which simply changes the recgroup.  I don't know why someone put that in there when it's so easy to just:
>>
>> UPDATE recorded SET recgroup = 'Cancelled' WHERE chanid = '1071' AND starttime = '20141103200000';
> Well if you insist on making your self look stupid and silly, then make ridiculous comparisons like that.
>
> Clearly, the examples you give are "designed for the job". Since there is no "designed for the job" function that will automagically (in my example) setup the channels as I like them, then it needs to be done via an alternative method.

No, the right solution is to have designed for the job functionality to 
do whatever you need more easily than can be done with even SQL.

> Applying reductio ad absurdum then hardly anything in Myth makes sense. If you persist in deliberately trying to make out that I have a different position to what I express, then you could argue that the whole scheduler is redundant as the user could do that themselves. The playback system is redundant as the user could just use (eg) VLC to playback a file. The user could manually delete files as the disk fills up. Etc, etc, etc.
>
> Put another way, what goes into Myth are all the functions that "most people need".

Yes, and if all these "SQL is the answer" threads have shown anything, 
it's that "most people" actually /do/ need a lot more functionality than 
MythTV offers in the UI.  We need to add in generic data selection and 
manipulation functionality such that--since we've been talking about 
editing channel lists, I'll stick with that example--in the mythtv-setup 
and backend web server channel editor, the user can select a bunch of 
channels by specifying arbitrary criteria and/or by manual selection and 
then apply changes to all of them (i.e. set them all as not visible or 
disable EIT on all of them or increase channel number by 
1/5/10/25/100/1000 or do whatever).  And we need to do similarly for 
recordings--select a bunch using arbitrary criteria and/or manual 
selection, and then apply any user-editable data change to them all--and 
anything else that users may need to edit...

>   What doesn't go in is special functions that only a few people need. You seem to be arguing that because I point out the proposed changes make those special functions less easy to do, that is somehow equivalent to arguing that the common functions should be removed.

such that nearly everything almost every user needs to do can be done 
via the user interface even more easily than it can be done with SQL, so 
that when they need to do something that's unique/broken/wrong (where 
I'll guess most all of the time it will fall into the latter 2 
categories since people's requirements aren't nearly as unique as they 
presume) they can either write or find a script (in the Scripts category 
of the wiki or whatever) that allows them to do what they want.  And 
even if it is "harder" to use the Python bindings than SQL, it will be 
such an uncommon occurrence (and/or it's just a matter of writing a 
script once and using it forever), that it won't matter.  In other 
words, the goal is for scripting (in SQL or Python or whatever) to be 
the exception and not--as it seems to be today (at least to some 
users)--the rule.

So I really do intend to remove MENU|Playlist Options|Storage 
Options|Change Recording Group and MENU|Storage Options|Change Recording 
Group (and all similar functionality, including those I mentioned in my 
previous reply) from mythfrontend and instead have functionality which 
allows changing /any/ user-editable data easily for a single recording 
or multiple at once.  You may fear the "user-editable" qualifier in 
there, but shouldn't because "user-editable" includes everything except 
MythTV-internal values that can't be changed without breaking things 
(like database IDs).  If the internal-only data needs changing, that 
means there's a serious bug in MythTV and the proper fix is to fix the 
bug, not allow user editing of the internal-only values via the UI.

MythTV has a lot of user-editable data, and much of it users don't even 
realize they can edit (such as recording title/subtitle/description), 
often because they can't find the option in the UI.  Having a single 
place to go to edit whatever data makes it easy to edit anything.  And, 
for those who are worried that it's going to take more remote button 
presses to toggle the watched flag or whatever since you'll have to 
navigate around the data you're not wanting to change, you should be 
able to do it as easily or more easily than you can now because I see 
these screens as getting customizable menus, like the customizable OSD 
menus that Jim Stichnoth added.

Mike


More information about the mythtv-users mailing list