Properties for Airing and/or Show objects?

[Slugger]

Is there a reason that airings nor shows have properties? If they could, it would be most appreciated. If not, I'll probably roll my own plugin to add this feature. I love using the properties features on media files and favs because I don't have to worry about cleaning them (i.e. delete the object, the properties are deleted automatically).

I'm looking to remove the need for my separate SQL database for the next version of SRE and in order to do this I need to be able to store some metadata about airings and/or shows else where. Ideally, I'd like to be able to use Get/SetShowProperty() and Get/SetAiringProperty() type API methods. If this isn't possible, I think I'll write a plugin that provides this ability in a separate plugin (backed by probably an SQL database) and at least be able to remove the SQL db from SRE.

If this isn't possible, is there a technical reason why? I kind of assume there is b/c otherwise I figure it would have been introduced at the same time the rest of the property abilities were added for other objects.

[tmiranda]

I think for Airings you can use GetAiringManualRecordProperty(), I'm pretty sure that works for any Airing, not just one that is a Manual Recording.

For Shows there isn't much you can do unless you use AddShow and "hide" the properties somewhere in the MiscList[].

Tom

[Slugger]

Originally Posted by tmiranda

I think for Airings you can use GetAiringManualRecordProperty(), I'm pretty sure that works for any Airing, not just one that is a Manual Recording.

Anyone know for sure if this is correct? If so, then I'm set as far as SRE is concerned. I'd still have a use for Show object properties, if it were available (for other things).

EDIT: The javadocs aren't clear. As I read them, the method should only work if an airing becomes a manual recording. If it happens to work and store props for any airing, even ones not scheduled to record, then that might be an unintentional feature/bug, which could be squashed at any point in the future. Hopefully Narflex will clear this up on Monday.

EDIT 2: Quick test in Groovy shows that the props don't persist for airings that aren't scheduled to record. So I'm back to my original request.

For Shows there isn't much you can do unless you use AddShow and "hide" the properties somewhere in the MiscList[].

Tom

I'd roll my own plugin backed by a separate SQL db before going this route.

[GKusnick]

This was asked and answered once before. As I recall, the issue is that Airing and Show objects are volatile and get deleted and recreated during EPG updates. Faves and Manuals persist and therefore can support custom metadata properties.

[Slugger]

Yeah, I thought we had this discussion before, but it seems to me that the objects are recreated with the same id because when I, for example, use an airing id as the key in my SRE db, that key remains valid and points to the same airing object for days or is this an incredibly lucky coincidence? So my point, I guess, is that even though these objects might be deleted and recreated with EPG updates, the key values remain unchanged after each EPG update, which suggests that properties could be maintained in the core (perhaps in a separate table in wiz.bin, keyed by the object id, which is exactly what I end up doing anyway, just in a separate database).

Though now I realize that if I happened to try and clean my table of props in th SRE db during an EPG update then I probably could incorrectly figure an airing has disappeared. I should probably be checking for active EPG updates during my cleanup thread.

[tmiranda]

Originally Posted by Slugger

EDIT 2: Quick test in Groovy shows that the props don't persist for airings that aren't scheduled to record. So I'm back to my original request.

Thanks for checking. I use that method in one of my plugins but I always make sure the Airings are manual records.

[Narflex]

Originally Posted by Slugger

Yeah, I thought we had this discussion before, but it seems to me that the objects are recreated with the same id because when I, for example, use an airing id as the key in my SRE db, that key remains valid and points to the same airing object for days or is this an incredibly lucky coincidence? So my point, I guess, is that even though these objects might be deleted and recreated with EPG updates, the key values remain unchanged after each EPG update, which suggests that properties could be maintained in the core (perhaps in a separate table in wiz.bin, keyed by the object id, which is exactly what I end up doing anyway, just in a separate database).

While they usually do stay constant; they do have the possibility of changing if the EPG update warrants a change...due to that volatility we don't want to add this as usage of it would then quite often have unexpected results.