Recording Rules API changes

Want to write your own code to work with a HDHomeRun or work with the HDHomeRun DVR? We are happy to help with concepts, APIs, best practices.
Post Reply
nickk
Silicondust
Posts: 16234
Joined: Tue Jan 13, 2004 9:39 am
x 75

Recording Rules API changes

Post by nickk »

API change in progress (not yet live):

Concept change:
A series can have exactly one series rule, plus any number of one-time-recording rules (unique DateTimeOnly rules).
Multiple teams can be specified in the TeamOnly field by using the '|' character as the separator.
Multiple channels can be specified in the ChannelOnly field by using the '|' character as the separator.

Add rule changes:
If a rule exists that prevents the creation of the new rule the add request is rejected.

Delete rule changes:
Deleting by SeriesID + TeamOnly is no longer supported. The TeamOnly parameter is ignored and the main series rule is deleted.

Changes to the returned json:
Filter/FilterTags is no longer returned.

signcarver
Expert
Posts: 9322
Joined: Wed Jan 24, 2007 1:04 am
Device ID: 10802091 131B34B7 13231F92 1070A18E 1073ED6F 15300C36
x 24

Re: Recording Rules API changes

Post by signcarver »

The multiple channels feature is what I've wanted for awhile and thanks for documenting it as I would have expected an array and I've seen a few different ways to send arrays via URL and your implementation seems to be easier than many.

I know in the past I had had multiple team rules... I believe I have deleted most but did notice I still have a few for college football. Will these be migrated to a single rule?

Edit: Also to clarify by Add Rule changes... I know in the past many developers always used add rather than change. Might there be an issue with those when a rule exists.

djp952
Posts: 1289
Joined: Wed Oct 01, 2008 8:46 pm
Device ID: 131EB7F7;131ED0E0
Location: Elkridge, MD USA
x 10

Re: Recording Rules API changes

Post by djp952 »

Sounds like all good things to me and I don't foresee any negative impacts to what I work on.

Perhaps for the add rule being rejected (I use Cmd=change to update existing rules), if the response can include the reason the request failed that would be nice. I assume the behavior otherwise would be to just return 'null' as the JSON response. Providing the reason for the failure would allow applications to prompt the user with that message instead of something generic like 'Add recording rule failed". I mean, the application should know that there is already a series rule in place before it tries to add another one, but bugs and logic errors happen. Having the cause would be helpful.

signcarver
Expert
Posts: 9322
Joined: Wed Jan 24, 2007 1:04 am
Device ID: 10802091 131B34B7 13231F92 1070A18E 1073ED6F 15300C36
x 24

Re: Recording Rules API changes

Post by signcarver »

One thing I just thought of but probably won't be implemented is perhaps make channel order important as a way to specify tuning priority when on at the same time.

I've always used change as my first apps were based on modifying existing rules... then a few figured it was just as easy to always use add but I guess I would like to know what would cause the old rule to prevent the creation of the new rule.

nickk
Silicondust
Posts: 16234
Joined: Tue Jan 13, 2004 9:39 am
x 75

Re: Recording Rules API changes

Post by nickk »

New API documentation:
https://github.com/Silicondust/document ... ding-Rules

The new API will go live early Monday morning.

Nick

Post Reply