Allow Access to ListItem Properties via JSON-RPC
#1
Star 
As the title states, this is a request to make ListItem Properties (as set by xbmcgui.ListItem.SetProperty(...)) available via a request to the JSON-RPC API.

Not being able to, as is the case now, has a number of implications for inter-addon communication, including, but not limited to, un/watched counts, resume points, extra item metadata, and even context menu items.

My proposed solution (albeit not one I'm prepared to tackle myself, as I'm not primarily a C++ developer, nor am I familiar in any way with Kodi's main codebase) would be to have available properties on a ListItem be included in the response from Files.GetDirectory, either as a separate object, or as part of the pre-existing properties object from the response. Provided someone with a bit more knowledge on the codebase could lend some guidance on where in the project these changes may be relevant, I could certainly take a whack at it!

I've also considered various workarounds to this issue, and detailed them in a different thread (along with an example add-on that basically serves to show that they are not reasonable approaches), but have not really made any headway, nor have I gotten any response. It is my belief that the correct way to handle this is to include them in the JSON-RPC response, so as to make this a standard operation, and not one that different developers will have to each find their own workaround for.
Reply
#2
(2020-06-15, 21:56)drinfernoo Wrote: As the title states, this is a request to make ListItem Properties (as set by xbmcgui.ListItem.SetProperty(...)) available via a request to the JSON-RPC API.

Not being able to, as is the case now, has a number of implications for inter-addon communication, including, but not limited to, un/watched counts, resume points, extra item metadata, and even context menu items.

My proposed solution (albeit not one I'm prepared to tackle myself, as I'm not primarily a C++ developer, nor am I familiar in any way with Kodi's main codebase) would be to have available properties on a ListItem be included in the response from Files.GetDirectory, either as a separate object, or as part of the pre-existing properties object from the response. Provided someone with a bit more knowledge on the codebase could lend some guidance on where in the project these changes may be relevant, I could certainly take a whack at it!

I've also considered various workarounds to this issue, and detailed them in a different thread (along with an example add-on that basically serves to show that they are not reasonable approaches), but have not really made any headway, nor have I gotten any response. It is my belief that the correct way to handle this is to include them in the JSON-RPC response, so as to make this a standard operation, and not one that different developers will have to each find their own workaround for.
On the surface this seems like a minor request; however, the work required to register and store custom properties for a future JSON response is complex. I'm not sure the memory impact of your request; I'd assume the team would have to go the route of storing locally to the DB; which then would require additional code for sql maintenance.

It would be a neat feature, but I don't see it happening anytime soon. I personally hijack lesser-used listitem keys for passing custom entries.

BTW: your plugin example has a number of unorthodox lines of code... which are going to pose problems down the road.
Image Lunatixz - Kodi / Beta repository
Image PseudoTV - Forum | Website | Youtube | Twitter | Help?
Reply
#3
(2020-06-16, 01:07)Lunatixz Wrote:
(2020-06-15, 21:56)drinfernoo Wrote: As the title states, this is a request to make ListItem Properties (as set by xbmcgui.ListItem.SetProperty(...)) available via a request to the JSON-RPC API.

Not being able to, as is the case now, has a number of implications for inter-addon communication, including, but not limited to, un/watched counts, resume points, extra item metadata, and even context menu items.

My proposed solution (albeit not one I'm prepared to tackle myself, as I'm not primarily a C++ developer, nor am I familiar in any way with Kodi's main codebase) would be to have available properties on a ListItem be included in the response from Files.GetDirectory, either as a separate object, or as part of the pre-existing properties object from the response. Provided someone with a bit more knowledge on the codebase could lend some guidance on where in the project these changes may be relevant, I could certainly take a whack at it!

I've also considered various workarounds to this issue, and detailed them in a different thread (along with an example add-on that basically serves to show that they are not reasonable approaches), but have not really made any headway, nor have I gotten any response. It is my belief that the correct way to handle this is to include them in the JSON-RPC response, so as to make this a standard operation, and not one that different developers will have to each find their own workaround for.
On the surface this seems like a minor request; however, the work required to register and store custom properties for a future JSON response is complex. I'm not sure the memory impact of your request; I'd assume the team would have to go the route of storing locally to the DB; which then would require additional code for sql maintenance.

It would be a neat feature, but I don't see it happening anytime soon. I personally hijack lesser-used listitem keys for passing custom entries.
For what it's worth, I believe the impact would be minimal, though I could be wrong.

When a call to Files.GetDirectory is made, the entire code at that endpoint is executed, including log statements, external calls, properties being set, etc... which leads be to believe that they can be read "in the same breath" as all of the other InfoLabels. I'm not saying this isn't a non-trivial change, but rather that I don't expect it would be a major one.

EDIT: I'm open to criticism on my code, I'm still learning Wink
Reply
#4
(2020-06-16, 01:15)drinfernoo Wrote:
(2020-06-16, 01:07)Lunatixz Wrote:
(2020-06-15, 21:56)drinfernoo Wrote: As the title states, this is a request to make ListItem Properties (as set by xbmcgui.ListItem.SetProperty(...)) available via a request to the JSON-RPC API.

Not being able to, as is the case now, has a number of implications for inter-addon communication, including, but not limited to, un/watched counts, resume points, extra item metadata, and even context menu items.

My proposed solution (albeit not one I'm prepared to tackle myself, as I'm not primarily a C++ developer, nor am I familiar in any way with Kodi's main codebase) would be to have available properties on a ListItem be included in the response from Files.GetDirectory, either as a separate object, or as part of the pre-existing properties object from the response. Provided someone with a bit more knowledge on the codebase could lend some guidance on where in the project these changes may be relevant, I could certainly take a whack at it!

I've also considered various workarounds to this issue, and detailed them in a different thread (along with an example add-on that basically serves to show that they are not reasonable approaches), but have not really made any headway, nor have I gotten any response. It is my belief that the correct way to handle this is to include them in the JSON-RPC response, so as to make this a standard operation, and not one that different developers will have to each find their own workaround for.
On the surface this seems like a minor request; however, the work required to register and store custom properties for a future JSON response is complex. I'm not sure the memory impact of your request; I'd assume the team would have to go the route of storing locally to the DB; which then would require additional code for sql maintenance.

It would be a neat feature, but I don't see it happening anytime soon. I personally hijack lesser-used listitem keys for passing custom entries.
For what it's worth, I believe the impact would be minimal, though I could be wrong.
I don't see how it would be a minimal impact, I believe you are thinking solely of your plugin and not Kodi as a whole with multiple plugins storing their own respective properties of varying size and type (ie not all values will be strings).
(2020-06-16, 01:15)drinfernoo Wrote: When a call to Files.GetDirectory is made, the entire code at that endpoint is executed, including log statements, external calls, properties being set, etc... which leads be to believe that they can be read "in the same breath" as all of the other InfoLabels. I'm not saying this isn't a non-trivial change, but rather that I don't expect it would be a major one.

Currently, GetDirectory can only return a finite amount of keys; custom properties could be near infinite.
You're more than welcome to give it a shot: https://github.com/xbmc/xbmc ... otherwise, it can only be suggested in hopes someone takes on the work.
Image Lunatixz - Kodi / Beta repository
Image PseudoTV - Forum | Website | Youtube | Twitter | Help?
Reply
#5
(2020-06-16, 01:23)Lunatixz Wrote:
(2020-06-16, 01:15)drinfernoo Wrote:
(2020-06-16, 01:07)Lunatixz Wrote: On the surface this seems like a minor request; however, the work required to register and store custom properties for a future JSON response is complex. I'm not sure the memory impact of your request; I'd assume the team would have to go the route of storing locally to the DB; which then would require additional code for sql maintenance.

It would be a neat feature, but I don't see it happening anytime soon. I personally hijack lesser-used listitem keys for passing custom entries.
For what it's worth, I believe the impact would be minimal, though I could be wrong.
I don't see how it would be a minimal impact, I believe you are thinking solely of your plugin and not Kodi as a whole with multiple plugins storing their own respective properties of varying size and type (ie not all values will be strings).
(2020-06-16, 01:15)drinfernoo Wrote: When a call to Files.GetDirectory is made, the entire code at that endpoint is executed, including log statements, external calls, properties being set, etc... which leads be to believe that they can be read "in the same breath" as all of the other InfoLabels. I'm not saying this isn't a non-trivial change, but rather that I don't expect it would be a major one.

Currently, GetDirectory can only return a finite amount of keys; custom properties could be near infinite.
You're more than welcome to give it a shot: https://github.com/xbmc/xbmc ... otherwise, it can only be suggested in hopes someone takes on the work.
I simply don't see how it could be more of an impact. There would be basically no extra time needed for "persisting" them, as they would just be being returned on the fly, just as the InfoLabels do... so why not just append them to the response "as they are set"? I realize this is all an oversimplification, and admittedly due to my own inexperience Big Grin

I'm absolutely willing to give it a shot, as I mentioned in my original post... but I really have no idea where I'd even begin to look inside the codebase.

I'm simply trying to figure out a solution to this. Unfortunately, as outlined in my other thread (and demonstrated by my example), there isn't even a way to get one of the properties "on-demand", even if I know which property I'm looking at ahead of time.
Reply
#6
(2020-06-16, 01:32)drinfernoo Wrote:
(2020-06-16, 01:23)Lunatixz Wrote:
(2020-06-16, 01:15)drinfernoo Wrote: For what it's worth, I believe the impact would be minimal, though I could be wrong.
I don't see how it would be a minimal impact, I believe you are thinking solely of your plugin and not Kodi as a whole with multiple plugins storing their own respective properties of varying size and type (ie not all values will be strings).
(2020-06-16, 01:15)drinfernoo Wrote: When a call to Files.GetDirectory is made, the entire code at that endpoint is executed, including log statements, external calls, properties being set, etc... which leads be to believe that they can be read "in the same breath" as all of the other InfoLabels. I'm not saying this isn't a non-trivial change, but rather that I don't expect it would be a major one.

Currently, GetDirectory can only return a finite amount of keys; custom properties could be near infinite.
You're more than welcome to give it a shot: https://github.com/xbmc/xbmc ... otherwise, it can only be suggested in hopes someone takes on the work.
I simply don't see how it could be more of an impact. There would be basically no extra time needed for "persisting" them, as they would just be being returned on the fly, just as the InfoLabels do... so why not just append them to the response "as they are set"? I realize this is all an oversimplification, and admittedly due to my own inexperience Big Grin

I'm absolutely willing to give it a shot, as I mentioned in my original post... but I really have no idea where I'd even begin to look inside the codebase.

I'm simply trying to figure out a solution to this. Unfortunately, as outlined in my other thread (and demonstrated by my example), there isn't even a way to get one of the properties "on-demand", even if I know which property I'm looking at ahead of time.
Guess its one of those things will have to see when/how its implemented; however, InfoLabels are loaded into memory; nothing on the fly about it them. They are not listitems rather a dynamic representation of a single listitem key. From my recollection, there is NO connection between them and JSONRPC getDirectory.
Image Lunatixz - Kodi / Beta repository
Image PseudoTV - Forum | Website | Youtube | Twitter | Help?
Reply
#7
(2020-06-16, 01:49)Lunatixz Wrote:
(2020-06-16, 01:32)drinfernoo Wrote:
(2020-06-16, 01:23)Lunatixz Wrote: I don't see how it would be a minimal impact, I believe you are thinking solely of your plugin and not Kodi as a whole with multiple plugins storing their own respective properties of varying size and type (ie not all values will be strings).

Currently, GetDirectory can only return a finite amount of keys; custom properties could be near infinite.
You're more than welcome to give it a shot: https://github.com/xbmc/xbmc ... otherwise, it can only be suggested in hopes someone takes on the work.
I simply don't see how it could be more of an impact. There would be basically no extra time needed for "persisting" them, as they would just be being returned on the fly, just as the InfoLabels do... so why not just append them to the response "as they are set"? I realize this is all an oversimplification, and admittedly due to my own inexperience Big Grin

I'm absolutely willing to give it a shot, as I mentioned in my original post... but I really have no idea where I'd even begin to look inside the codebase.

I'm simply trying to figure out a solution to this. Unfortunately, as outlined in my other thread (and demonstrated by my example), there isn't even a way to get one of the properties "on-demand", even if I know which property I'm looking at ahead of time.
Guess its one of those things will have to see when/how its implemented; however, InfoLabels are loaded into memory; nothing on the fly about it them. They are not listitems rather a dynamic representation of a single listitem key. From my recollection, there is NO connection between them and JSONRPC getDirectory.

You're saying that even though the code run in my directory, as a result of making a JSON-RPC call to Files.GetDirectory then basically ignores what metadata and properties I've attached to my ListItems, and then has to go off searching for the actual values in another, somehow persisted, location? Rather than using the ones that have just been set, by me?
Reply
#8
(2020-06-16, 03:15)drinfernoo Wrote:
(2020-06-16, 01:49)Lunatixz Wrote:
(2020-06-16, 01:32)drinfernoo Wrote: I simply don't see how it could be more of an impact. There would be basically no extra time needed for "persisting" them, as they would just be being returned on the fly, just as the InfoLabels do... so why not just append them to the response "as they are set"? I realize this is all an oversimplification, and admittedly due to my own inexperience Big Grin

I'm absolutely willing to give it a shot, as I mentioned in my original post... but I really have no idea where I'd even begin to look inside the codebase.

I'm simply trying to figure out a solution to this. Unfortunately, as outlined in my other thread (and demonstrated by my example), there isn't even a way to get one of the properties "on-demand", even if I know which property I'm looking at ahead of time.
Guess its one of those things will have to see when/how its implemented; however, InfoLabels are loaded into memory; nothing on the fly about it them. They are not listitems rather a dynamic representation of a single listitem key. From my recollection, there is NO connection between them and JSONRPC getDirectory.

You're saying that even though the code run in my directory, as a result of making a JSON-RPC call to Files.GetDirectory then basically ignores what metadata and properties I've attached to my ListItems, and then has to go off searching for the actual values in another, somehow persisted, location? Rather than using the ones that have just been set, by me?

You're confusing infoLabels,Listitems,JSONRPC different things. some infoLabels build from listitems and "Files.GetDirectory" does NOT return a listitem directly.

For your example; "Files.GetDirectory" would run your plugin:// path and build a listitem as per your code.
Image Lunatixz - Kodi / Beta repository
Image PseudoTV - Forum | Website | Youtube | Twitter | Help?
Reply
#9
(2020-06-16, 03:42)Lunatixz Wrote:
(2020-06-16, 03:15)drinfernoo Wrote:
(2020-06-16, 01:49)Lunatixz Wrote: Guess its one of those things will have to see when/how its implemented; however, InfoLabels are loaded into memory; nothing on the fly about it them. They are not listitems rather a dynamic representation of a single listitem key. From my recollection, there is NO connection between them and JSONRPC getDirectory.

You're saying that even though the code run in my directory, as a result of making a JSON-RPC call to Files.GetDirectory then basically ignores what metadata and properties I've attached to my ListItems, and then has to go off searching for the actual values in another, somehow persisted, location? Rather than using the ones that have just been set, by me?

You're confusing infoLabels,Listitems,JSONRPC different things. some infoLabels build from listitems and "Files.GetDirectory" does NOT return a listitem directly.

For your example; "Files.GetDirectory" would run your plugin:// path and build a listitem as per your code.

Yes, that's exactly how I understand it as well. It runs my code, builds a ListItem, and then returns me an incomplete (not including properties) JSON representation of that item. My complaint is that when running code from a particular directory, where these values are set and available (the last time this is the case, before the directory is displayed... because after that, they are unavailable via any method besides a parsed $INFO tag in the skin), there is no reason I can imagine why they can't be returned like any of the other values.
Reply
#10
(2020-06-16, 03:50)drinfernoo Wrote:
(2020-06-16, 03:42)Lunatixz Wrote:
(2020-06-16, 03:15)drinfernoo Wrote: You're saying that even though the code run in my directory, as a result of making a JSON-RPC call to Files.GetDirectory then basically ignores what metadata and properties I've attached to my ListItems, and then has to go off searching for the actual values in another, somehow persisted, location? Rather than using the ones that have just been set, by me?

You're confusing infoLabels,Listitems,JSONRPC different things. some infoLabels build from listitems and "Files.GetDirectory" does NOT return a listitem directly.

For your example; "Files.GetDirectory" would run your plugin:// path and build a listitem as per your code.

Yes, that's exactly how I understand it as well. It runs my code, builds a ListItem, and then returns me an incomplete (not including properties) JSON representation of that item. My complaint is that when running code from a particular directory, where these values are set and available (the last time this is the case, before the directory is displayed... because after that, they are unavailable via any method besides a parsed $INFO tag in the skin), there is no reason I can imagine why they can't be returned like any of the other values.

API's work within a schema; predefined keys. I'm not aware of any APIs that allow for custom entries. If a "Custom property" component was ever added to the rpc I imagine It would most likely be a single defined key ex "Properties" that could return a dictionary value set by a developer ie. "Properties":{"Custom_Key_1":"foo","Custom_Key_2":"Bar"}
Image Lunatixz - Kodi / Beta repository
Image PseudoTV - Forum | Website | Youtube | Twitter | Help?
Reply
#11
files != listitems

Files.GetDirectory returns a directory listing (i.e. files), it does not return listitems.
so you can get the file properties (filesize, modified date), but that's about it.

since plugins are a virtual file system, running Files.GetDirectory on a plugin path will also return a file listing.

there isn't any method in our json api that will return listitems.
Do not PM or e-mail Team-Kodi members directly asking for support.
Always read the Forum rules, Kodi online-manual, FAQ, Help and Search the forum before posting.
Reply
#12
(2020-06-16, 04:08)ronie Wrote: files != listitems

Files.GetDirectory returns a directory listing (i.e. files), it does not return listitems.
so you can get the file properties (filesize, modified date), but that's about it.

since plugins are a virtual file system, running Files.GetDirectory on a plugin path will also return a file listing.

there isn't any method in our json api that will return listitems.

I'm aware that it returns files... but the ListItems are still created and still have the properties set. Why is there a hard limitation that says I am not longer allowed to access those properties at a later time?

EDIT: I did mention previously that I'm aware if returns me a JSON representation of the ListItem (i.e., the underlying "file"). There are methods provided for retrieving a ListItem from a playlist, or in XML, as in a skin or add-on window, but none of those methods will allow a different (or even the same) plugin to access those properties after the directory has been created initially.

EDIT 2: After reading back at this part:
Quote:so you can get the file properties (filesize, modified date), but that's about it.
Except that's not really "about it"... I can request any "InfoLabel" equivalent, as defined by List.Fields.Files, and am able to recreate a ListItem with almost the exact metadata as the one represented in JSON, except there is no way to retrieve specifically ListItem properties. Everything else you (or me, anyways) could want is accessible via JSON-RPC.
Reply
#13
Is there anyone that is actually familiar with the workings of the JSON-RPC mechanism? I'd like to try and assist in making this work, but am having trouble figuring out where in Kodi's codebase that code would actually be run...

I'm assuming that there's "directory creation" sections of code, and "directory traversal" sections that interface with the JSON-RPC, but I'm not sure where either of those are Big Grin
Reply
#14
The JSON stuff is here -> https://github.com/xbmc/xbmc/tree/master...s/json-rpc . More specifically, GetDirectory() and GetFileDetails() are here https://github.com/xbmc/xbmc/blob/master...ations.cpp  if that's any help.
Learning Linux the hard way !!
Reply
#15
Ok, so I've been looking at how things work in the sections linked above, and I found something peculiar. CFileItemHandler::GetField is where it appears that the JSON-RPC mechanism does the bulk of the work in "parsing" the directory it gets passed. There are a few instances where it handles properties that it finds in the request:
I should point out that the music- and TV-specific properties I'm referring to here are ListItem properties. However, last but not least, the final condition:
Which leads me to believe that any property which does not satisfy one of the preceding six conditions, would at least trigger a check, and attempt to append the value of that property to the response.

However, upon further investigation, and looking deeper into how JSON schemas and the JSON-RPC API work, I've found that it actually isn't allowed to send any additional properties. The documentation on the wiki indicates that "additionalProperties" are a supported feature of JSON schemas, and the default behavior, when additional properties are found in a schema, is actually to allow them (an empty schema, allowing any value). However, by the time that the JSON is parsed for properties, additional properties, and unique properties, there is something happening that triggers the message: Received value does not match any of the defined enum values.

It seems that by using an enum type in the schema, this method precludes itself from being able to accept additional properties... Which means this may be "as simple" as changing the schema to allow them in one way or another. This would ideally not affect any code that isn't already using them (since they can't), and wouldn't be a complexity concern, as the properties would only be queried when requested from the API.

So, a question for the more experienced developers that may have touched the API more in-depth than myself: Does this logic follow, or am I in a completely different field?
Reply



Logout Mark Read Team Forum Stats Members Help
Allow Access to ListItem Properties via JSON-RPC0
This forum uses Lukasz Tkacz MyBB addons.