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
|
- jasonvp - 2011-09-03 Montellese Wrote:Hey everyone Hi Guys, Are these added to the Nightly Builds? I'm using the Windows 01-Sep-2011 10:28 version and I tried: Code: {"jsonrpc":"2.0","id":1,"method":"AudioLibrary.GetSongs","params":{"fields":["artistid","albumid"]}} Response: Code: {"error":{"code":-32602,"data":{"method":"AudioLibrary.GetSongs","stack":{"message":"array element at index 0 does not match","name":"fields","property":{"message":"Received value does not match any of the defined enum values","type":"string"},"type":"array"}},"message":"Invalid params."},"id":1,"jsonrpc":"2.0"} Cheers Jason - topfs2 - 2011-09-03 jasonvp Wrote:I'm using the Windows 01-Sep-2011 10:28 version and I tried: Check if the revisions mentioned are in the source used to compile that nightly, its not possible to derive this information simply from date (likely is that you just missed it in that nightly so take a newer version) - jasonvp - 2011-09-03 topfs2 Wrote:Check if the revisions mentioned are in the source used to compile that nightly, its not possible to derive this information simply from date (likely is that you just missed it in that nightly so take a newer version) Installed XBMCSetup-20110902-312d2c3-master.exe and all is working fine. Thanks topfs2. You guys do a great job. Cheers Jason - samdret - 2011-09-04 Montellese Wrote:Not directly but what you can try is to call Files.GetDirectory with the path to the directory in which your file is. You will also have to provide the media type of the file so that JSONRPC is able to check the right database for the details of the file. Tried that, but only got back fanart, label and file - none of which are of particular interest - Montellese - 2011-09-04 samdret Wrote:Tried that, but only got back fanart, label and file - none of which are of particular interest What version of XBMC are you running? Have you stated in your request to Files.GetDirectory which optional fields you would like to retrieve? - rflores2323 - 2011-09-04 rflores2323 Wrote:I was running xbmc before. Closed it and did what you said above. here you go below. Any help - Montellese - 2011-09-05 We are currently working hard to get a stable and future-proof jsonrpc API which we can extend in the future without having to remove any unneeded stuff so I am working on cleaning up all the namespaces so that we won't have to do that at a later point. Monday, September 5th 2011: Major cleanup Commits: 8 commits from 2a33c5f4696d2c079625 to 2968c9b8faf821f70e97 Ok these 8 commits contain all kinds of cleanup in the jsonrpc API to make it more future-proof. From now on everything that resides in the XBMC namespace is either very XBMC-specific or is something that is more of a hack than anything else (like GetInfoLabels and GetInfoBooleans)
- dann0 - 2011-09-06 testing a nightly build on the weekend i ran into an issue connecting to the JSON-RPC server via TCP. the build i was using was XBMCSetup-20110902-312d2c3-master.exe 03-Sep-2011 10:28 i suspect the issue was the lack of a 'new line' character at the end of the data stream. to test i connected to xbmc's (nightly) json-rpc server using telnet, sent a request and observed the response, the cursor remained positioned at the end of the data stream. i then connected to version 10.1 and sent the same request, at the end of the response the cursor was positioned on a new line. - Montellese - 2011-09-06 dann0 Wrote:testing a nightly build on the weekend i ran into an issue connecting to the JSON-RPC server via TCP. IIRC this has been reported before by someone else but it is not a bug. If you use jsonrpc over TCP and you don't use a json(rpc) library to parse the data stream you cannot rely on something like "a response ends when there is a } followed by a newline character". All you can do is count how many { and } there are. We changed the internal json library we use in XBMC since Dharma because that one had some flaws and the new json implementation does not send a newline character at the end of a request but in jsonrpc everything that is not encapsulated between { and } is garbage and has to be thrown away so leaving it away in the beginning is even better. JSON bracket counting - othrayte - 2011-09-06 Montellese Wrote:IIRC this has been reported before by someone else but it is not a bug. If you use jsonrpc over TCP and you don't use a json(rpc) library to parse the data stream you cannot rely on something like "a response ends when there is a } followed by a newline character". All you can do is count how many { and } there are. We changed the internal json library we use in XBMC since Dharma because that one had some flaws and the new json implementation does not send a newline character at the end of a request but in jsonrpc everything that is not encapsulated between { and } is garbage and has to be thrown away so leaving it away in the beginning is even better. I believe I was the person that brought it up originally in relation to my work on Trakt Utilities. @dann0 I implemented the bracket counting in python at the time and we have been using it in TU for a while now without problems, but I don't guarantee that it is perfect. Your welcome to use the code (it is GPLv2 licensed) and you can see it in context here https://github.com/Manromen/script.TraktUtilities/blob/master/notification_service.py. Not sure if your using python or something else but the general idea should work the same in different languages. The important part is this bit: Code: if bCount == 0: This code runs inside a loop, it waits for some partial data and goes back to the start of the loop to wait for more when it hasn't reached the end and continues through to the json.loads when it finds a whole block, this is where you would handle the data itself. I hope this helps, if you have any questions I'm happy to answer them, but a pm would probably be best. - gertjanzwartjes - 2011-09-06 Montellese Wrote:GetInfoLabels and GetInfoBooleans have been moved from the System to the XBMC namespace and are considered deprecated. Please let us know which data you retrieve most using these methods so that we can provide better access to those values. I'm using Window.IsActive(), to figure out whether some window is currently showing and active, using Window IDs as specified in guilib/Key.h. - Montellese - 2011-09-06 gertjanzwartjes Wrote:I'm using Window.IsActive(), to figure out whether some window is currently showing and active, using Window IDs as specified in guilib/Key.h. Thanks for the feedback. Wrapping part of the GUI is on the TODO list so checking active windows will most likely be available directly in the future. - dann0 - 2011-09-07 Montellese Wrote:IIRC this has been reported before by someone else but it is not a bug. If you use jsonrpc over TCP and you don't use a json(rpc) library to parse the data stream you cannot rely on something like "a response ends when there is a } followed by a newline character". All you can do is count how many { and } there are. We changed the internal json library we use in XBMC since Dharma because that one had some flaws and the new json implementation does not send a newline character at the end of a request but in jsonrpc everything that is not encapsulated between { and } is garbage and has to be thrown away so leaving it away in the beginning is even better. Thanks for your reply Montellese. I made a feature request and copied you and topfs2 in. I realise it may not interest many users, so i won't be holding my breath i just thought i would throw it out there anyways. Expose Scrapers to JSON - Jeff17 - 2011-09-07 I've created a patch to expose some of the scraper methods. Right now this is using the "Scraper." namespace, but after reading this ticket, it looks like it might be better to rename it. So far I've created three methods: Scraper.GetScrapers(type) will return a list of active, installed scrapers (file=scraperid, label=scrapername) filtered by the type specified Scraper.FindMovie( scraperid, file ) will use a specific scraper and return a list of matching results (file=scraperurl, label=movie name). Filename can be the path to the file or search terms. Scraper.GetMovieDetails( scraperid, url, fields ) will query a scraper and return a list of movie details. The existing code is mostly just a proof-of-concept. I'm interested in hearing what functionality we want to expose over JSON and what naming conventions I should be using for this. Thanks! -- Jeff - gertjanzwartjes - 2011-09-07 Montellese Wrote:Thanks for the feedback. Wrapping part of the GUI is on the TODO list so checking active windows will most likely be available directly in the future. Ok, that's good to hear, thanks. When something is available I'll be able to test it out and report back. One more thing, the current nightly JSON-RPC API provides methods for movement (Left, Right, Up, ...). I was wondering whether more generic keyboard input is planned as well? Mostly to be able to provide keyboard functionality to edit setting strings, or when adding a source, etc. I'm still relying on the HTTP API for that, but I'm wondering if I should make the switch to EventServer or not. |