Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#10734 closed Patch - Feature (fixed)

Dynamic Variable Evaluation for Power Search (Extension)

Reported by: mmm1976@… Owned by: gigem
Priority: minor Milestone: 0.26
Component: MythTV - General Version: 0.25
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Hi all,

I'm proposing an extension for the "custom edit" (power search).


Why I did this: First, I started scheduling with "record daily in this timeslot" because I just wanted to record daily in that timeslot. I figured out that the start of my show was shifter +/-5min and it was never recorded. There was a patch for "use some slack on recording starttime" to fix this problem 4 years ago. But it was never integrated and it was closed about 3 months ago.

I was told, that for something like I wanted there would be "custom edit" or "power search". I find it quite painfull to enter SQL-commands via remote control, so I got the idea that there should be something like dynamic variable evaluation for power searching. Something like that:

program.title = '{TITLE}' AND TIME_TO_SEC(TIME(program.starttime)) >= {STARTSEC}-600 AND TIME_TO_SEC(TIME(program.endtime)) <= {ENDSEC}+600

This could be stored as sample-clause for the custom-edit dialog and could be dynamically evaluated and filled with date from the program guide.


How is it used with stored rules? Go to program-guide -> select a show -> menu -> recording options -> custom edit. Delete the default "program.title = '...'" from the edit box. Select your stored custom example e.g. "timeslack timeslot" (above). Press SELECT (OK). Press "test" or "record". Finished.

It's fast and easy :-)


How does it work and how do I create such rules? Go to program-guide -> select a show -> menu -> recording options -> custom edit. Now you can enter the example above and test, record or store the rule.

If you select "test" or "record" the recording rule is evaluated before it is tested or it is recorded. If you select "store" you can store your unevaluated rule in the database as custom example rule.

Now the tricky part to explain: The default is that stored rules with variables are evaluated by default. You can select an example rule and see something like this in the small box on the right.

program.title like 'Simpsons' AND TIME_TO_SEC(TIME(program.starttime)) >= 10000-600 AND TIME_TO_SEC(TIME(program.endtime)) <= 12000+600

When pressing "E" ("EDIT") you can toggle between enabled and disabled evaluation. So, if you want to edit a stored rule with variables, you could disable evaluation, select the rule you want to edit and press OK (select) in order to copy the unevaluated rule to the edit box. Then you could edit it and store it again.

For instance: Select "timeslack timeslot"-Rule, press "E" until the unevaluated rule is displayed, press SELECT (OK). Then it is copied to the edit box where you can edit it. When pressing "TEST" or "RECORD" it is evaluated before the rule is tested or recorded (but it doesn't change the edit box).

There are a couple of variables:

TITLE : m_pginfo->GetTitle() 
SUBTITLE : m_pginfo->GetSubtitle()
DESCR : m_pginfo->GetDescription()
SERIESID :m_pginfo->GetSeriesID()
PROGID : GetProgramID()
SEASON : m_pginfo->GetSeason()
EPISODE :m_pginfo->GetEpisode();
CATEGORY : m_pginfo->GetCategory();
CHANID : m_pginfo->GetChanID();
CHANNUM : m_pginfo->GetChanNum();
SCHEDID : m_pginfo->GetChannelSchedulingID();
CHANNAME : m_pginfo->GetChannelName();
DAYNAME : m_pginfo->GetScheduledStartTime().toString("dddd"); (SQL dayname format)
STARTDATE : m_pginfo->GetScheduledStartTime().toString("yyyy-mm-dd hh:mm:ss"); (SQL datetime format)
ENDDATE : m_pginfo->GetScheduledEndTime().toString("yyyy-mm-dd hh:mm:ss"); (SQL datetime format)
STARTTIME :m_pginfo->GetScheduledStartTime().toString("hh:mm");
ENDTIME : m_pginfo->GetScheduledEndTime().toString("hh:mm");
STARTSEC : (program.starttime seconds since midnight)
ENDSEC : (program.endtime seconds since midnight)

How does it affect other users? Not at all. If they didn't know it exists, they wouldn't notice anything at all about changed behaviour :-) Though, I changed the pre-existing samples for use with the variables mentioned above (where applicable), but as I said, nothing visibly changed :-)

Feedback welcomed.

Attachments (2)

customedit.patch (14.9 KB) - added by mmm1976@… 12 years ago.
customedit.2.patch (10.7 KB) - added by mmm1976@… 12 years ago.
with diff -Naur

Download all attachments as: .zip

Change History (12)

Changed 12 years ago by mmm1976@…

Attachment: customedit.patch added

Changed 12 years ago by mmm1976@…

Attachment: customedit.2.patch added

with diff -Naur

comment:1 Changed 12 years ago by gigem

Status: newinfoneeded_new

This patch is unlikely to be accepted because I don't see any significant value over what can already be done using existing features. I'm willing to listen, however, so I'm setting this ticket to infoneeded for now instead of closing it outright.

First, have you tried the Find Daily rule type? It was created specifically to record one showing of a program per day. It can often be used as a simple way to handle programs that are on once a day with fuzzy start times.

Second, do you know that custom rules have access to specific values from the recording rule? For example, to match the title in a generic way, all you need to add is "program.title = RECTABLE.title". "RECTABLE" should always be used in place of "record" for reasons that I won't elaborate on here.

Third, if you find you're always using the exact same SQL clauses for most of your custom rules, you can add them as filters and then easily use them with regular rules. Take a look at the standard filters. They are essentially snippets of custom rules tat you can toggle on or off for individual rules.

comment:2 Changed 12 years ago by mmm1976@…

First: Yes, I have tried this. But it doesn't work for my show, because sometimes there are 2 occurences of the show within 24h (e.g. the first starts at 7PM, the second on 6.55PM on the next day). I tried everything (and hat loooong chats about the scheduler with sphery in the chat). The only thing I wanted was a timeslot recording rule which is tolerant for time-shifts. Of course it's just an example and it can be used for much more.

Second: I don't see how this could do the same. The variables are filled with the information of the selected show in the program guide. The sense behind is that e.g. something like {STARTTIME} is dynamically evaluated to 36000 if the show which was selected in the EPG starts at 10AM. (How can I access data from scheduled programs, I haven't scheduled yet?)

Third: Not the SQL clause is the same, the expression is the same. {STARTTIME} depends on the show you selected and is a variable which is then evaluated. No way you could do a static filter for it.

You store custom-edit examples with variables like {TITLE} or {STARTTIME} and these variables are replaced by real data coming from the program guide before the rule is stored in the recodings table. There was no mechanism in mythtv which would have allowed something like this.

comment:3 Changed 12 years ago by mmm1976@…

I knew I forgot something ...

Of course, everything should be fast and easy with a simple remote control ... I didn't want to use the onscreen keyboard and I don't have a real keyboard plugged on my computer.

I know the "filter dialog" but the filter rules are not directly customizable (only in the database by hand) and the space is very limited (too few lines on the screen).

comment:4 in reply to:  2 ; Changed 12 years ago by gigem

Replying to mmm1976@…:

First: Yes, I have tried this. But it doesn't work for my show, because sometimes there are 2 occurences of the show within 24h (e.g. the first starts at 7PM, the second on 6.55PM on the next day). I tried everything (and hat loooong chats about the scheduler with sphery in the chat). The only thing I wanted was a timeslot recording rule which is tolerant for time-shifts. Of course it's just an example and it can be used for much more.

There is a hidden time for Find Daily (and Weekly) rules that defines when the "day" begins. If you choose the 7pm showing when you create the rrule, the day will begin at 7pm and the scheduler will always try to record the 7pm showing before falling back to 6:55pm showing the next day.

Second: I don't see how this could do the same. The variables are filled with the information of the selected show in the program guide. The sense behind is that e.g. something like {STARTTIME} is dynamically evaluated to 36000 if the show which was selected in the EPG starts at 10AM. (How can I access data from scheduled programs, I haven't scheduled yet?)

Third: Not the SQL clause is the same, the expression is the same. {STARTTIME} depends on the show you selected and is a variable which is then evaluated. No way you could do a static filter for it.

You store custom-edit examples with variables like {TITLE} or {STARTTIME} and these variables are replaced by real data coming from the program guide before the rule is stored in the recodings table. There was no mechanism in mythtv which would have allowed something like this.

There is something I don't think you understand. When a rule is created, and also when it is edited later, values from the program on which you chose to bring up the schedule rule editor are copied into the rule. IOW, your variables (or at least the important ones that matter) are already there in the record table. For example, the program starttime is one of those values. You can then create a "Fuzzy starttime" filter by using the following SQL:

ABS(TIME_TO_SEC(TIMEDIFF(TIME(program.starttime), RECTABLE.starttime))) < 900

If you then set a rule type to "record at any time on any channel" or "record at any time on this channel" and enable the filter, you effectively create a daily recording rule that will match starttime +/- 15 minutes. Please note that there isn't a GUI yet for users to add their own filters.

You can do the same type of thing with custom rules and stored examples. Unfortunately, there is a problem I ran into while testing. The sanity test that must be passed before you are allowed to create a recording rule doesn't account for the record table references. I'll have to see what I can do about that.

comment:5 in reply to:  4 Changed 12 years ago by gigem

Replying to gigem:

You can do the same type of thing with custom rules and stored examples. Unfortunately, there is a problem I ran into while testing. The sanity test that must be passed before you are allowed to create a recording rule doesn't account for the record table references. I'll have to see what I can do about that.

I just realized this isn't applicable to search rules because the relevant information is not added to the record table. I still think filters are applicable to most things you want to do.

comment:6 Changed 12 years ago by mmm1976@…

Okay, you are right with the filter. But as you already admitted, they are not customizable (yet?). And they can't be changed with a simple remote control.

The extension I proposed is a quite generic approach which doesn't affect any user who doesn't know the feature extisted.

I thought, there would be some people interested in something like this, because it also is possible to create custom rules like "record this show repeatedly only on the current {DAYNAME} and record with time slack of 10min and ..." or "record this on {DAYOFWEEK} and {DAYOFWEEK}+1. I don't know, how static filters would work here and I can't imagine they are more easy. My approach is straight forward and explains itself. And it can be used for much more I haven't thought about yet.

comment:7 Changed 12 years ago by mmm1976@…

What I also wanted to mention: The customedit dialog already had samples which were filled with the data from the program guide. Like my example above with {DAYNAME}. But it was hardcoded in the source that {DAYNAME} is only filled in this single example "Anytime on a specific day of the week". I changed the sample from:

rule.description = QString("DAYNAME(program.starttime) = '%1' ").arg(m_pginfo->GetScheduledStartTime().toString("dddd"));

to

rule.description = QString("DAYNAME(program.starttime) = '{DAYNAME}' ");

I think that makes sense because the code becomes more consistent.

comment:8 Changed 12 years ago by gigem

Owner: set to gigem

I'll probably commit your patch in a few days. I'd like to take some time to see if there's anything I'd like done in a cleaner or simpler way. Feel free to ping me if I forget to do anything with this.

FYI, there are long-term plans to remove the ability to edit raw SQL for custom rules. When that happens, this feature might go away.

comment:9 Changed 12 years ago by David Engel <dengel@…>

Resolution: fixed
Status: infoneeded_newclosed

In f38e299719dac707be0189aece01b4ff342c6293/mythtv:

Allow deferred evaluation when creating custom recording rules.

When creating a custom rule by choosing "Custom Edit" for a program,
allow the use of variables such as "{TITLE}" and "{STARTTIME}". The
variables are replaced with actual values from the program when the
rule is saved. This allows storing sample searches for future re-use
that will automatically adapt to the new program. Press "EDIT" to
toggle between immediate evaluation (the previous and default
behavior) and deferred evaluation.

This change is primarily from used mmm1976, with trivial changes by
me.

Fixes #10734

comment:10 Changed 12 years ago by Raymond Wagner

Milestone: unknown0.26
Note: See TracTickets for help on using tickets.