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 - Montellese - 2012-09-18 (2012-09-18, 15:40)Millencolin007 Wrote: But it would be a good thing if Files.GetDirectory always returns the artist the same way. Otherwise it does not match the definition from the json schema and it prevents you to use some higher level api to parse json objects directly to java.I thought that I had adjusted that in the JSON schema but maybe I'm wrong. Will fix. In your code you should just be able to check whether it's an array or a string and go from there. (2012-09-18, 15:40)Millencolin007 Wrote: I already use the addons:// path in Music Pump to browse through the music and video addons but it has some issues(pops up progress dialogs on xbmc, search masks are hidden behind the progress dialog etc...) Those dialogs also make json-rpc block sometimes until the dialogs are clicked away. Far from perfect but it works AFAIK that's a generally known bug in XBMC which should be fixed since today (or yesterday, I don't remember). RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - roli - 2012-09-18 Thank you for answering my question that fast. But I have another one. How can I get the filename of the media that is currently played? Or usually called label when you are browsing all files. The "Player.GetItem" can return many details but I don't see any option to get the file name. Problem is because my media is not sorted in library - I am just too lazy, so I am using XBMC to only play files. So I need the filename. EDIT: Just figured out that passing an empty array in the request will return the label and type. Is that considered a "valid" solution? RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Tolriq - 2012-09-18 (2012-09-18, 15:43)Montellese Wrote:(2012-09-18, 15:40)Millencolin007 Wrote: But it would be a good thing if Files.GetDirectory always returns the artist the same way. Otherwise it does not match the definition from the json schema and it prevents you to use some higher level api to parse json objects directly to java.I thought that I had adjusted that in the JSON schema but maybe I'm wrong. Will fix. In your code you should just be able to check whether it's an array or a string and go from there. There's case like direct Class mapping in high level Json usage or direct streaming parsing in low level where checking if string or array or null depending on case is not really possible or needs very ugly hacks with bad perfomances. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Millencolin007 - 2012-09-18 (2012-09-18, 17:57)Tolriq Wrote: There's case like direct Class mapping in high level Json usage or direct streaming parsing in low level where checking if string or array or null depending on case is not really possible or needs very ugly hacks with bad perfomances. I know. I am using gson since I was already familiar with this library and liked its direct json to class mapping. Gson has a streaming mode which is nice for large data sets since it reads junk by junk. There is a function peek() which allows you to test the type of an object before processing it. This works actually really well but is a low level api which requires to write a lot of (boring) code. I was trying to use direct class mapping for all requests which are not performance critical and used two different classes, one for api v4 and one for api v5 (after the big json change in august). But since Files.GetDirectory can return a string or an array in api level v5 this wasn't working properly. I think that it is possible to write a small deserializer to handle the array/string case properly. I just have to look into it. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-09-18 (2012-09-18, 17:47)roli Wrote: Thank you for answering my question that fast. But I have another one. How can I get the filename of the media that is currently played? Or usually called label when you are browsing all files. The "Player.GetItem" can return many details but I don't see any option to get the file name. Problem is because my media is not sorted in library - I am just too lazy, so I am using XBMC to only play files. So I need the filename. "label" and "type" are always returned because the provide the most basic data. You can also request the "file" property if you want to get the path to the file including the filename. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Tolriq - 2012-09-18 (2012-09-18, 19:24)Millencolin007 Wrote:(2012-09-18, 17:57)Tolriq Wrote: There's case like direct Class mapping in high level Json usage or direct streaming parsing in low level where checking if string or array or null depending on case is not really possible or needs very ugly hacks with bad perfomances. For database sync I use direct streaming from Jackson that is the speediest way ATM and using the less memory / cpu and GC and yes handling such case is really a pain in ..... RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-09-18 There's no way out of this situation that will please everyone. On one hand you get different types for "artist" depending on what path you retrieve on the other hand you get different results for "artist objects". Furthermore there's no easy way to handle this in xbmc either because if artist information is retrieved from the database, the "artist" property is stored as a string whereas in other cases (album etc) it is stored as an array. Changing that in core might break other stuff (which is why generic properties are a PITA). RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Tolriq - 2012-09-19 Well since for this there's way to resolve this is not a total break so not a major problem, the more complicated thing is to find those specials as the null for streams that we might not have in our testing libraries and will break parsing until handled I don't know how, but perhaps adding some warning in the introspect would help RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-09-19 I agree that there needs to be some kind of rule on what to do if a certain property doesn't exist for a specific item or is empty. The problem with "is empty" is that there's not always a proper definition of "empty". Maybe someone set some specific string to "" on purpose so on one hand it's empty but on the other it's intended so it's not equal to "doesn't exist". As you all seem to have problems handling null'ed properties would it be better to just drop the properties which would return null? RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Tolriq - 2012-09-19 For direct parsing and object mapping this would be easier yes RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-09-21 OK I've pushed a commit that will make sure no "null" values are returned in a JSON-RPC response. Furthermore "streamdetails" will no longer be returned if there are no stream details available. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Tolriq - 2012-09-21 Thanks Any idea of jmarshall return date ? RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Mizaki - 2012-09-21 Lets see how it's broken mine ;p RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Skindred - 2012-09-22 (2012-05-15, 14:35)Montellese Wrote:(2012-05-15, 14:10)dwagner Wrote: I'm having issues with the nightly builds (currently I am using the 12 May nightly build). I use Simple REST Client to do JSON testing in chrome, and it keeps giving me: Hi Montellese, I too am having this issue where I get 415 Unsupported Media Type However, the Content-Type is set to application/json-rpc I am using jsonrpclib (python) by jmarshall, and the Content-Type seems to be hardcoded into the egg. So my question here is; is it possible to add application/json-rpc to the list? I have installed Eden Stable, and functionality still works there, so it's just a matter of recognizing application/json-rpc as json aswell. Kind regards, Skindred RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - N3MIS15 - 2012-09-22 you could simply change the lib. Change line 120 in jsonrpc.py to: Code: connection.putheader("Content-Type", "application/json") While changing the lib is not the best solution.. If you include the lib in your app it should be safe. This is how we got around it in Maraschino. I also wrote my own class to behave exactly like jsonrpclib if you're interested, it does not support batch requests tho. http://forum.xbmc.org/showthread.php?tid=135074&pid=1138156#pid1138156 |