JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32) +--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93) +---- Forum: JSON-RPC (https://forum.kodi.tv/forumdisplay.php?fid=174) +---- Thread: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC (/showthread.php?tid=68263) Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
|
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - jmarshall - 2013-11-05 This is possibly a NULL versus empty issue perhaps? RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-06 (2013-11-05, 23:38)jmarshall Wrote: This is possibly a NULL versus empty issue perhaps? Presumably you mean in C++ terms, as specifying a null filter value isn't valid for JSON. It most likely is something like that though, or perhaps it's down to a join query, as I'm surprised that "value != '@@@@@'" manages to ignore all those movies where set == "" as in theory these should also be returned but aren't. Edit: I should add that "startswith/endswith" are both working as expected, contrary to my previous comment about only contains/doesnotcontain working, however neither are useful for what I'm trying to achieve, indeed is/isnot works with everything but an empty string, but support for empty strings would be most welcome! Edit2: Just to be sure, I went back to a version with v6.6.2 API (so prior to all the recent JSON API updates) and the is/isnot filter with an empty string is also not working there, so this doesn't appear to have been introduced recently. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2013-11-06 Looking at the code it seems that we throw away filters that contain no or an empty value which could explain this behaviour. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-06 (2013-11-06, 18:46)Montellese Wrote: Looking at the code it seems that we throw away filters that contain no or an empty value which could explain this behaviour. Yes it would! Hopefully it can be fixed, I'd have thought it would be be quite useful to know when a value is set (isnot "") or unset (is ""), but you don't know (or care) what value it is. Another example might be to obtain a list of movies that have a "lastplayed" value set, presumably a 'lastplayed isnot ""' query would fail (be ignored) too. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Regss - 2013-11-06 I'm trying to get watched movies: Code: {"jsonrpc": "2.0", "method": "VideoLibrary.GetMovies", "params": {"properties": ["playcount"]}, "filter": {"operator": "greaterthan", "field": "playcount", "value": 0}, "id": 1} but get list of all movies with unwatched. Frodo 12.2 RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-06 (2013-11-06, 20:19)Regss Wrote: I'm trying to get watched movies: Try passing value as a string ("0") - this works for me in Frodo (v6.0.3 JSON API) and Gotham (v6.12.0), but passing "value" as an integer (0) causes an error in both - the following is from Frodo/v6.0.3, first an integer then a string: Code: REQUEST: {"jsonrpc": "2.0", "params": {"filter": {"operator": "greaterthan", "field": "playcount", "value": 0}, "properties": ["playcount"]}, "method": "VideoLibrary.GetMovies", "id": "libMovies"} RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Regss - 2013-11-06 Thanks, I see mistake now. I wrong created a query. Filter must be pass as params. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-07 Another example of the null filter ignored problem - filtering GetTextures returning just those artwork items without a hash, ie. 'lasthashchecked is ""' - this too returns everything. Obviously I can accomplish this query if hitting the Textures db directly with SQLite, but not via the new JSON API. Not sure why this hasn't cropped up before... RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-08 On the Addons.ExecuteAddon method there's a "wait" parameter, however the "wait" parameter doesn't appear to have any effect. For instance: Code: {"jsonrpc": "2.0", "method": "Addons.ExecuteAddon", "params": {"addonid": "script.artwork.downloader", "params": ["silent=true", "mediatype=movie"], "wait": true}, "id": "1"} doesn't wait for the addon to complete, it returns immediately after starting the addon - is this correct? RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-10 @Montellese: It's been a bit of a saga and this post may be a little long winded, but I hope you can bear with me... I've become aware of at least two addons that are "mangling" urls in the media library by creating urls with a mixture of forward and backwards slashes, for instance (and I think this was caused by Artwork Downloader): Code: "art": { Note the banner, clearart, clearlogo, discart and landscape urls with the Unix-style forward slash between the last directory and artwork filename, even though the urls are clearly for a Windows system. Although not right, these mangled urls don't seem to be a problem for the GUI - despite the media library referencing a "mangled" url, the GUI will locate the artwork successfully and then cache it without any problem, creating a similarly mangled url entry in the texture database. Now comes the problem: when requesting artwork with mangled urls via the webserver, it appears that the webserver is correcting the forward/backward slashes in the url and will create an entry in the texture database that is not mangled. Consequently, the GUI cannot find this cached item (as the GUI is looking for the mangled version of the url) and will proceed to create another cache entry, this time using the mangled url as it appears in the media library. Is there any way that the webserver can be made to stop correcting mangled filenames on-the-fly whenever it creates (or possibly even looks up) a row in the texture cache? This no-touch behaviour would then be consistent with the GUI caching behaviour. Alternatively I suppose the GUI could correct urls on the fly, but I'm guessing that's going to cause more overhead and is not ideal. Here's a worked example: Code: [ Note how the poster has a Windows-style backslash between the directory and filename. Having removed all trace of the poster from Textures13.db, the poster is downloaded using JSON and the webserver: JSON "Files.PrepareDownload" Request: Code: {"jsonrpc": "2.0", "params": {"path": "image://nfs%3a%2f%2f192.168.0.3%2fmnt%2fshare%2fmedia%2fVideo%2fMoviesHD%5cZombieland%20(2009)%5bBDRip%5d-poster.jpg/"}, "method": "Files.PrepareDownload", "id": "preparedl"} JSON "Files.PrepareDownload" Response: Code: {"id":"preparedl","jsonrpc":"2.0","result":{"details":{"path":"image/image%3a%2f%2fnfs%253a%252f%252f192.168.0.3%252fmnt%252fshare%252fmedia%252fVideo%252fMoviesHD%255cZombieland%2520(2009)%255bBDRip%255d-poster.jpg%2f"},"mode":"redirect","protocol":"http"}} Webserver (HTTP) Request: Code: GET image/image%3a%2f%2fnfs%253a%252f%252f192.168.0.3%252fmnt%252fshare%252fmedia%252fVideo%252fMoviesHD%255cZombieland%2520(2009)%255bBDRip%255d-poster.jpg%2f All of the above urls contain the backward slash from the original url (ie. they're all "mangled" urls). Having downloaded the item, the following row appears in Textures13.db: Code: 031637|9/9993f35a.jpg|2013-11-10 03:32:41|2013-11-10 03:32:41|nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Zombieland (2009)[BDRip]-poster.jpg Note the corrected forward slash between directory and filename - the url is no longer mangled! Now browse to the same poster in the GUI, and the following row appears in Textures13.db: Code: 031638|b/ba80e1ed.jpg|2013-11-10 03:34:20|2013-11-10 03:34:20|nfs://192.168.0.3/mnt/share/media/Video/MoviesHD\Zombieland (2009)[BDRip]-poster.jpg Note how the url is as it appears in the media library, ie. mangled. The row inserted by the webserver (#31637) is ignored by the GUI. The webserver caching behaviour should be consistent with the GUI, but it's not - any chance of a fix? I can't think how changing the webserver caching behaviour would break an existing addon or script, but I guess that's always something to be considered. Happy to help test... Obviously it would be better if addons didn't create mangled urls, but ultimately the mangled urls they produce are not a problem for the GUI, only the webserver, and I can't see how it will be possible to prevent addons from continuing to create mangled urls, particularly those that insert rows directly into the database (JSON could perhaps fix urls as they are passed over?) Many thanks for your consideration! RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2013-11-10 Thanks for the detailed description. The problem is not in the webserver but in the way the paths are handled by the texture caching logic. I'll try to get jmarshall to look into it. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Milhouse - 2013-11-11 (2013-11-10, 19:02)Montellese Wrote: Thanks for the detailed description. The problem is not in the webserver but in the way the paths are handled by the texture caching logic. I'll try to get jmarshall to look into it. That would be great, thanks. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - learningit - 2013-11-11 I'm trying to update my addons to make full use of the json rpc but I can't figure out how to set the properties of a playlist item. I can use: {"jsonrpc": "2.0", "method": "Playlist.Getitems", "params": {"playlistid": 1, "properties": ["title", "album", "artist", "plot", "year", "genre","season", "episode", "duration", "showtitle", "tvshowid", "thumbnail", "file", "fanart", "streamdetails"]}, "id":1} to read the playlist items properties, even if they're not in the library, but I can't get the Playlist.Add method to set the properties and can't find another method which does it. {"jsonrpc": "2.0", "method": "Playlist.Add", "params": {"playlistid": 1, "item":{"file":"C:/Users/TV/AppData/Roaming/XBMC/userdata/something.mp4"}}, "id":1} works to set the playlist item file, but how do you set the other properties? I'm trying to change the following existing code to the json interface: u=sys.argv[0]+"?url="+urllib.quote_plus(url)+"&mode="+str(mode) liz=xbmcgui.ListItem(name, iconImage=dir_image, thumbnailImage=iconimage) liz.setInfo( type="Video", infoLabels={ "Title": name, "Plot": description, "Genre": genre, "Year": date } ) liz.setProperty( "Fanart_Image", fanart ) liz.addContextMenuItems(contextMenu_) xbmc.PlayList(1).add(u, liz) How can I accomplish this with the json rpc api? Thanks in advance. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2013-11-11 JSON-RPC can't do that. You'll have to stick with python to be able to set properties when adding an item to a playlist. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2013-11-11 (2013-10-29, 16:18)tiago Wrote: Hi everyone, Sorry for the late reply. I am the main developer and maintainer of XBMC's JSON-RPC API. Unfortunately I've been very short on time in the last couple of weeks/months and that's not gonna change anytime soon. If you have a list of questions, feel free to email me (montellese@xbmc.org) or send me a PM and I will try to answer them ASAP. |