node = createObject("roSGNode", "ContentNode")
?node.contentId, node.hasField("contentId") ' 0 true
Also, the Streams field formatting is broken in https://developer.roku.com/dev/docs/content-metadata
node = createObject("roSGNode", "ContentNode")
?node.contentId, node.hasField("contentId") ' 0 true
Also, the Streams field formatting is broken in https://developer.roku.com/dev/docs/content-metadata
The contentId field is a string value and is used, for example, in deeplinking. The use case is documented but if there is some other clarification you’re looking for please let us know.
Could you please link me to that documentation? The contentId you mentioned comes in to the scene via args through the entry point function in main.brs and it does not have to do with ContentNode. Also, when trying to set a string to a content node’s contentId field, it doesn’t work since the field is a roInt, resulting in the value remaining 0. This is how I discovered this field to begin with ![]()
This is the documentation for the ContentId as a string:
We don’t have anything where the contentId is an integer and our engineers were a bit confused about the value being an integer and not a string. They said we only have string values.
In your test code, you’re creating a node of type ContentNode which has all the various content-metadata fields defined by default.
I checked the field list, and there is a field called “ContentId” that has type int defined there. It has been there since at least 2019, so I can’t explain why it’s not in the official documentation. However, there are lots of field names here that are defined but not in the docs; for example, there’s one called “DvdOnly” that’s type boolean that is still there, but probably not very useful now.
The ContentNode type is special in Roku OS, and those fields aren’t taking up space when not used. I think the only problem would be if you’re trying to extent ContentNode and had your own field called ContentId that had non-numeric data in it. It is used internally in some of our C+±based UI for caching a value when populating items in a menu list, so we’re unlikely to change it.
Hey Ben! Thank you for the response and explanation. I just wanted to bring this up in case this was a mistake or some sort of a bug. I worked around it, but it did give me a couple of minutes of confusion as to why things weren’t working as I was expecting them to work. It’s no big deal, however I do wish that these hidden fields were documented somewhere. Thanks!