Custom recording rules

[mvallevand]

I am slightly embarrassed. After I sent you my database, I went back and looked at this again.

I didn't think it was bad at all, just not conducive to duplicate check across channels especially with the different sources. The problem with customization is if you decided you don't like the structure anymore, pattern matching for new episodes will fail.

The unique-id filed in the epg-event table is populated for every show that had a series and episode number in the source EPG data. I assume that the unique-id field is populated by NPVR when it does an updateepg.

I assumed that too, I hadn't seen that before but I know sub made change to improve things outside North America recently

I setup my recordings again. I set record one recurring record as all "TBBT" on Channel 4 and a second recurring record as all "TBBT" on E4. It appears that this is doing what I want and recording a single copy of every episode (i.e. no duplicates even though there are duplicates in the EPG).

Yes that is why I asked sub if his duplicate check will follow my rule, it is actually quite good on one rule.

As an experiment, I deleted the two existing recurring recordings and created a single new recurring recording - all episodes all channels. This did not record duplicates within itself (i.e. all new recordings were unique) but it did record duplicates of shows that were already recorded and in the database.

Once you delete a record with a uniqueid within a configured time frame it won't be re-recorded. That is another NextPVR rule that works very well.

I'm grateful that you are looking at this. My "requirement" seems to be evolving (but requirements always do!). I am trying to "build a library" of every episode of TBBT without duplicates and that takes account of the already recorded episodes ... select distinct from future broadcasts where not in (select from existing recordings).

That it is the basic piece I am adding

And finally, please don't do anything only and only on my account ... I can cope quite well with the recording functions that we already have. Thank you for listening.

I needed some rules that NextPVR didn't have for people coming from another recording utility and I thought these new rules might be applicable to a few NextPVR utilities. As you wrote the NextPVR rules work for most people, but if they extra power is there some people might find this useful.

Martin

[Graham]

That is another NextPVR rule that works very well.

It appears that the NextPVR "avoid duplicates" process tests column recurrence-oid and xml uniqueID in column event-details in table scheduled-recording to determine if a future show is a duplicate. This works well for shows that are recorded using a single item in the table recurring-recording and, therefore, have the same recurrence-oid.

A difficulty arises if we delete the recurring recording and create a new one. We get a new recurrence-oid and the "no duplicates" process ignores any existing recording.

I am writing this to satisfy myself that I understand what's going on and not because you need egg sucking lessons.

[mvallevand]

Graham,

Your understanding is the same as mine, which is why much earlier in this thread I asked for a variable from sub that will give the user the option to include the recurrence id in the selection of duplicates. Additionally in addition to selecting by channels and a new "not channel" filter, I allow for selecting from (not) channel_group so the rules don't have to removed and re-edited as often.

Martin

[sub]

It appears that the NextPVR "avoid duplicates" process tests column recurrence-oid and xml uniqueID in column event-details in table scheduled-recording to determine if a future show is a duplicate. This works well for shows that are recorded using a single item in the table recurring-recording and, therefore, have the same recurrence-oid.

A difficulty arises if we delete the recurring recording and create a new one. We get a new recurrence-oid and the "no duplicates" process ignores any existing recording.

That was the case, but the bug was worked through a few days ago in this thread: http://forums.nextpvr.com/showthread.php...recordings.

[mvallevand]

That was the case, but the bug was worked through a few days ago in this thread: http://forums.nextpvr.com/showthread.php...recordings.

Are you saying that the duplicate rule check now spans recurring events and that you also check the previously scheduled_recordings table for a unique id?

Martin

[sub]

Yes. Previously the unique id check was incorrectly only loading up and checking the set of unique ids associated with the recurring recording instead of all recordings. Now it's checking against all.

[Graham]

Now it's checking against all.

Plus, if I understand correctly, it also checks the recently-deleted table. If I set DeletionHistoryDays to, for example, 999 then I can record for three years without duplicates including no duplicates of the shows that I have watched during the last three years.

I am jolly impressed. Thank you.

[mvallevand]

Yes. Previously the unique id check was incorrectly only loading up and checking the set of unique ids associated with the recurring recording instead of all recordings. Now it's checking against all.

That's great I did a quick test and I see it is doing a perfect job against event_details

Code:

2012-10-15 19:38:45.244    [DEBUG][1]     - Potential episode at: 26/10/2012 7:00:00 PM
2012-10-15 19:38:45.245    [DEBUG][1]       ...check IsValid()
2012-10-15 19:38:45.245    [DEBUG][1]       ...already got this episode: EP009311820038
2012-10-15 19:38:45.245    [DEBUG][1]          existing status: STATUS_COMPLETED
2012-10-15 19:38:45.245    [DEBUG][1]          existing time: 16/03/2009 7:30:00 PM - 15/03/2009 8:00:00 PM
2012-10-15 19:38:45.245    [DEBUG][1]       ...already got this episode scheduled
2012-10-15 19:38:45.245    [DEBUG][1]     - Potential episode at: 26/10/2012 7:00:00 PM
2012-10-15 19:38:45.245    [DEBUG][1]       ...check IsValid()
2012-10-15 19:38:45.245    [DEBUG][1]       ...already got this episode: EP009311820038
2012-10-15 19:38:45.245    [DEBUG][1]          existing status: STATUS_COMPLETED
2012-10-15 19:38:45.245    [DEBUG][1]          existing time: 16/03/2009 7:30:00 PM - 15/03/2009 8:00:00 PM
2012-10-15 19:38:45.245    [DEBUG][1]       ...already got this episode scheduled
2012-10-15 19:38:45.245    [DEBUG][1]     - Potential episode at: 26/10/2012 7:00:00 PM
2012-10-15 19:38:45.245    [DEBUG][1]       ...check IsValid()
2012-10-15 19:38:45.245    [DEBUG][1]       ...already got this episode: EP009311820080
2012-10-15 19:38:45.245    [DEBUG][1]          existing status: STATUS_COMPLETED
2012-10-15 19:38:45.245    [DEBUG][1]          existing time: 20/01/2011 6:00:00 PM - 20/01/2011 6:30:00 PM
2012-10-15 19:38:45.245    [DEBUG][1]       ...already got this episode scheduled

Thanks for that. Hopefully you will still schedule for STATUS_FAILED.

Martin

[mvallevand]

This is definitely more a developer's tool but I've found it handy for using a select to query NPVR.db3 xml fields. It is described earlier and sub does have it implemented so it works with advancedrules

Enter the select statement in the text box and hit button1 eg

Code:

select oid, XmlLookup(event_details, "/Event/Title") as title, XmlLookup(event_details, "/Event/Description") as subtitle from SCHEDULED_RECORDING

Martin