[mythtv] Format of new post-0.25 config.xml

[Michael T. Dean]

On 06/02/2012 06:24 PM, Brian J. Murrell wrote:
> On 12-06-02 05:05 PM, Michael T. Dean wrote:
>> Just to prove to myself that a non-Python-enabled person could write
>> such a script using the fragment Raymond posted as a started, I went to
>> http://www.mythtv.org/wiki/0.25_Python_Bindings and used some of the
>> scripts at http://www.mythtv.org/wiki/Category:Python_Scripts as
>> examples and came up with:
>>
>> #!/usr/bin/env python
>> import MythTV
>> for prog in MythTV.MythBE().getPendingRecordings():
>>       if prog.recstatus != MythTV.Program.rsInactive:
>>           continue
>>       print "{0.callsign:<8} {0.title:<40} {0.subtitle:<30}
>> {0.starttime}".format(prog)
>>
>> (Note that I took out the channel/chanid stuff since I wasn't sure what
>> you were doing with that.)
> As Raymond said, yeah, just A/D to signify if it was being shown on an
> analog or a digital channel.
>
> But your snippet prints all inactive programs, including the ones that
> have already recorded episodes, not just "pilots and premiers".  But
> your point is taken.

No, it only prints episodes that are matched only by an inactive rule.  
All the other recstatus types ( 
https://github.com/MythTV/mythtv/blob/master/mythtv/bindings/python/MythTV/static.py#L59 
) are ignored--includingrsPreviousRecording, rsEarlierShowing, 
rsWillRecord, etc.  You could also filter by a specific recording rule 
using the prog.recordid to match the recordid of the First Episodes 
recording rule.  While you could hard-code the recordid, it's just as 
easy to look it up using code closer to what Raymond started with:

#!/usr/bin/env python
import MythTV
rules = [r.recordid for r in MythTV.Record.getAllEntries() if "First 
Episodes" in r.title]
for prog in MythTV.MythBE().getPendingRecordings():
#    if prog.recstatus != MythTV.Program.rsInactive:
     if prog.recordid not in rules:
         continue
     print "{0.recordid:<5} {0.callsign:<8} {0.title:<40} 
{0.subtitle:<30} {0.starttime}".format(prog)

> It doesn't change the fact that there is still some likely
> never-reusable learning curve to getting something that does what you
> want though.  I say "likely never-reusable" because it's use is so
> infrequent that it practically becomes the same learning curve every
> time, vs. the already-learned tools at hand.

Please don't try to say that your SQL left join with was "already 
learned"--you /definitely/ had to dig deep into the MythTV database 
schema and MythTV internal data representation to figure out that 
query--even if you happen to be a SQL expert (not to mention a 
sed/tr/bash expert :).  And, that query can break as MythTV changes 
(meaning you'll have to do it--and learn it--over again).  The 
bindings-based approach, however, will actually work even in the face of 
changes to MythTV because a) it asks the backend to interpret the data 
instead of doing so itself (by asking the backend for a list of programs 
that matched recording rules), and b) all it does is filter and display 
the information it's given.

> I'd still end up spending some amount of time figuring out how the
> classes work to take even your example to reach that only "pilots and
> premieres" stage.  If I had to script myth stuff more frequently, I
> fully admit that learning the binding might be worth it.
>
> Just perusing, the data returned does look interesting but the
> documentation of the classes doesn't seem to be entirely clear or
> complete.  I noticed that getPendingRecordings() returns a list of
> Program for example.  Clicking the link for Program I choose the 0.24
> page for it given that the Master choice seems to go nowhere.  The page
> on Data_Handlers has a brief description of a Program but I have to
> believe there are a lot more fields available than just those listed.
>
> I don't really mean this to be a critique of the lack of documentation,
> indeed, at all.  But just an observation on the amount of work that one
> would end up having to go through trawling the classes in the source to
> figure this all out.
>
> For example, how did you know "recstatus" was a member of the class
> Program?  And how did you find out about the rsInactive constant?

More than anything, I knew about those from knowing about the MythTV 
internal ProgramInfo class as well as the database program table.  The 
data types in the Python bindings are pretty much just mapped from the 
database tables.  However, a grep for "class Program" shows that it's 
defined in bindings/python/MythTV/mythproto.py , and lists the fields at 
https://github.com/MythTV/mythtv/blob/master/mythtv/bindings/python/MythTV/mythproto.py#L813 
.

And, as for the values for the recstatus field, the statics.py file I 
linked, above, shows those options.

Mike