+- 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 - Mizaki - 2012-07-01
I turned on debug in Eden to check but the times were roughly the same. Hopefully someone else using Linux can compare. The only difference is I run git with portable but I can't imagine that would make the difference. I'm sure when I tried the changes previously the times were around 100ms. If I can find anything definitive, skin, addons etc. I'll let you know.
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-07-01
I'm running in portable mode as well. When developing I run in portable mode in Confluence but both Eden and current master have the same movie sources with approximately 550 movies. Skins etc shouldn't have anything to do with this. The only other thing that can slow JSON-RPC request over HTTP down is if there are a lot of other requests at the same time. IIRC we handle 4 simultaneous requests (sounds low but that's what a lot of the big webservers like Apache etc do by default as well). But as there was no simultaneous HTTP request handling in Eden it would even be slower there.
I can try on linux sometime next weekend (got 4 exams coming up next week).
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Millencolin007 - 2012-07-02
Hi,
I was trying to update the playcount from a movie in order to mark a video as watched/unwatched in xbmc. (using latest nightly build)
Set movie as watched: Works, but lastplayed field in db is empty, shouldn't this be updated to the current date if playcount was 0 before?
Code:
curl -H "Content-Type: application/json" -d "{\"jsonrpc\": \"2.0\", \"method\": \"VideoLibrary.SetMovieDetails\", \"params\" : { \"movieid\" : 1, \"playcount\" : 1 }, \"id\" : 1 }" http://127.0.0.1:8080/jsonrpc | python -mjson.toolSet movie as watched: works
Code:
curl -H "Content-Type: application/json" -d "{\"jsonrpc\": \"2.0\", \"method\": \"VideoLibrary.SetMovieDetails\", \"params\" : { \"movieid\" : 1, \"playcount\" : 1, \"lastplayed\" : \"2012-07-02 11:25:37\" }, \"id\" : 1 }" http://127.0.0.1:8080/jsonrpc | python -mjson.toolSetting the movie as unwatched does not work. Tried the following two requests
Code:
curl -H "Content-Type: application/json" -d "{\"jsonrpc\": \"2.0\", \"method\": \"VideoLibrary.SetMovieDetails\", \"params\" : { \"movieid\" : 1, \"playcount\" : 0, \"lastplayed\" : \"\" }, \"id\" : 1 }" http://127.0.0.1:8080/jsonrpc | python -mjson.toolCode:
curl -H "Content-Type: application/json" -d "{\"jsonrpc\": \"2.0\", \"method\": \"VideoLibrary.SetMovieDetails\", \"params\" : { \"movieid\" : 1, \"playcount\" : 0 }, \"id\" : 1 }" http://127.0.0.1:8080/jsonrpc | python -mjson.toolboth return
Code:
{
"error" : {
"code" : -32602,
"data" : {
"method" : "VideoLibrary.SetMovieDetails",
"stack" : {
"message" : "Received value does not match any of the union type definitions",
"name" : "playcount",
"type" : ["null", "integer"]
}
},
"message" : "Invalid params."
},
"id" : 1,
"jsonrpc" : "2.0"
}[/quote]RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-07-02
(2012-07-02, 11:56)Millencolin007 Wrote: Hi,Thanks for mentioning it. I changed it in master.
I was trying to update the playcount from a movie in order to mark a video as watched/unwatched in xbmc. (using latest nightly build)
Set movie as watched: Works, but lastplayed field in db is empty, shouldn't this be updated to the current date if playcount was 0 before?
(2012-07-02, 11:56)Millencolin007 Wrote: Setting the movie as unwatched does not work. Tried the following two requestsFound the bug and fixed it as well. Thanks for letting me know.
Code:curl -H "Content-Type: application/json" -d "{\"jsonrpc\": \"2.0\", \"method\": \"VideoLibrary.SetMovieDetails\", \"params\" : { \"movieid\" : 1, \"playcount\" : 0, \"lastplayed\" : \"\" }, \"id\" : 1 }" http://127.0.0.1:8080/jsonrpc | python -mjson.tool
Code:curl -H "Content-Type: application/json" -d "{\"jsonrpc\": \"2.0\", \"method\": \"VideoLibrary.SetMovieDetails\", \"params\" : { \"movieid\" : 1, \"playcount\" : 0 }, \"id\" : 1 }" http://127.0.0.1:8080/jsonrpc | python -mjson.tool
both return
Code:{
"error" : {
"code" : -32602,
"data" : {
"method" : "VideoLibrary.SetMovieDetails",
"stack" : {
"message" : "Received value does not match any of the union type definitions",
"name" : "playcount",
"type" : ["null", "integer"]
}
},
"message" : "Invalid params."
},
"id" : 1,
"jsonrpc" : "2.0"
}
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Mizaki - 2012-07-04
When you have a spare minute I'm still getting a segfault with pre-frodo.
Code:
{"jsonrpc": "2.0", "method": "VideoLibrary.GetMovies", "params": { "limits": { "start" : 303, "end": 349 }, "properties" : ["rating", "thumbnail", "playcount", "file"], "sort": { "order": "ascending", "method": "label", "ignorearticle": true } }, "id": 1}Code:
std::_Rb_tree<Field, std::pair<Field const, CVariant>, std::_Select1st<std::pair<Field const, CVariant> >, std::less<Field>, std::allocator<std::pair<Field const, CVariant> > >::_M_erase (this=0xad1f7e8, __x=0x1)
at /usr/include/c++/4.6/bits/stl_tree.h:1064
1064 _M_erase(_S_right(__x));Anything else I can do to try and find the problem?
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-07-05
(2012-07-04, 19:23)Mizaki Wrote: When you have a spare minute I'm still getting a segfault with pre-frodo.
If "start" is <303 it seems to work. I ran gdb and crashed it. I have no idea with gdb so this may be no help whatsoever.Code:{"jsonrpc": "2.0", "method": "VideoLibrary.GetMovies", "params": { "limits": { "start" : 303, "end": 349 }, "properties" : ["rating", "thumbnail", "playcount", "file"], "sort": { "order": "ascending", "method": "label", "ignorearticle": true } }, "id": 1}
http://pastebin.com/KRiYz30ACode:std::_Rb_tree<Field, std::pair<Field const, CVariant>, std::_Select1st<std::pair<Field const, CVariant> >, std::less<Field>, std::allocator<std::pair<Field const, CVariant> > >::_M_erase (this=0xad1f7e8, __x=0x1)
at /usr/include/c++/4.6/bits/stl_tree.h:1064
1064 _M_erase(_S_right(__x));
Anything else I can do to try and find the problem?
Fixed in https://github.com/xbmc/xbmc/commit/76b11c2c002f1310019dddcaf6b8076f009eb234
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Mizaki - 2012-07-05
That's great, thanks.
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Tolriq - 2012-07-09
(2012-06-04, 16:55)Montellese Wrote: Yes after Eden jmarshall has changed the way XBMC caches images. They are now referenced with an URI of the following schema:
and that's also what you should get through JSON-RPC. You should still be able to URL-encode the whole image URI you get through JSON-RPC and call http://<ip>:<port>/vfs/<url encoded image path> but you should switch to using http://<ip>:<port>/image/<url encoded image path> which (in the future) will provide additional functionality like automatic image resizing during retrieval etc. So basically nothing has changed, the returned URIs just look different.Code:image://<url encoded uri from where the image originally came>
I'm trying the yesterday alpha and it seems there's some speed problems.
This request on same numbers of movies ( Request : {"id":1,"jsonrpc":"2.0","method":"VideoLibrary.GetMovies","params":{"properties":["director","genre","plot","rating","runtime","sorttitle","studio","thumbnail","title","trailer","playcount","year"]}}) takes like 1 sec more (around 1000 movies)
And the very most annoying part the image download are slowwwwwwwwwwwwwwwwww (i still use the /vfs).
Image takes like 10 time more times to download on android perhaps more.
I use optimizations that should only download the file header then download the file in an optimised way for target small resolution
Don't really know what it does with webserver but worked perfect before Frodo.
The used code : (Image size is 240 for my batch downloads of thumbs).
Code:
private Bitmap downloadImage(ImageInfo image, int ImageSize) {
Bitmap b = null;
try {
InputStream is;
int scale = 1;
// Decode image size
if (ImageSize > 0) {
BitmapFactory.Options o = new BitmapFactory.Options();
o.inJustDecodeBounds = true;
is = getImageStream(image, NETWORK_TIMEOUT);
BitmapFactory.decodeStream(is, null, o);
is.close();
is = null;
if (o.outHeight > ImageSize || o.outWidth > ImageSize) {
scale = (int) Math.pow(
2,
(int) Math.round(Math.log(ImageSize
/ (double) Math.max(o.outHeight, o.outWidth))
/ Math.log(0.5)));
}
}
// Decode with inSampleSize
BitmapFactory.Options o2 = new BitmapFactory.Options();
if (ImageSize > 0) {
o2.inSampleSize = scale;
}
o2.inJustDecodeBounds = false;
o2.inDither = true;
o2.inScaled = false;
o2.inPreferredConfig = Bitmap.Config.RGB_565;
is = getImageStream(image, NETWORK_TIMEOUT);
b = BitmapFactory.decodeStream(is, null, o2);
is.close();
is = null;
} catch (Exception e) {
if (Logger.LOG_WARN)
Logger.LogWarning(TAG, "Exception : " + e.getMessage());
}
return b;
}RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Millencolin007 - 2012-07-09
I am using a similar piece of code to download images. The code is actually still downloading the whole file but uses less memory on the android device to decode the file into a bitmap.
And since some images are sent in 1920x1080 it is slow to fetch the files.
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Tolriq - 2012-07-09
Well the problem is :
Same Android code / same database same images (I use multi threaded limited to 2 thread on my SIII for tests).
- Eden : image are correctly downloaded 2 by 2 more than 10 images in 1 sec.
- Frodo : image seems to have troubles being downloaded 2 by 2 and it's more 1,5 sec / image
And I repeat same code same database same images
Edit : And of course same phone same computer 2 install in portable mode
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Tolriq - 2012-07-09
Ok got it
Using /vfs or /image is clearly not the same
I should have figured out earlier but did not focus on correct things for tests
But using /vfs will get the original file that can be a 3MB full sized png from source (Can be a web server or a slow NAS).
(BTW using /vfs/image:// does not work so I stupidely removed the image:// part)
Using /image will get the cached image that is correctly resized by xbmc and local to xbmc.
That explain the very big speed difference, should be clearly stated for people that will port from Eden to Froyo
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - jmarshall - 2012-07-10
Requesting thumbnail is an extra query per movie, so that will be slow.
For the image download, my guess (and it's just a guess) is that the images you have in your texture cache are much larger than they were in Eden - reason is that there was a period of about 2-3 months where they were cached at fullsize. If that's the case, then you have to transfer much more data across the network to do the resize. Latest master (i.e. after the music thumbs were slotted in) will cache art at a lower resolution, so this should speed things up (they'll be cached at around 1/4 the size as before).
Oh, and if using vfs (which you shouldn't in frodo, ofcourse!) the image:// URL you pass in has to be URL encoded, else it won't work.
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Tolriq - 2012-07-10
See my last post
The problem was more a problem about /vfs and not a problem with /image that works ok.
Edit :
- Why is the thumb send from JSON already urlencoded ? this lead to have the url encoded twice ?
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - mikebzh44 - 2012-07-10
Is there a way to get last added favourites with JSON RPC ?
Thanks.
EDIT : I think it's not possible the way some users use favourites :
http://forum.xbmc.org/showthread.php?tid=122448&pid=1144455#pid1144455
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-07-10
(2012-07-10, 00:12)Tolriq Wrote: Edit :Because otherwise it's not a valid URL. The way it is now you can take whatever JSON-RPC provides you for thumbs/fanart and directly pass it to the /image handler of XBMC's webserver.
- Why is the thumb send from JSON already urlencoded ? this lead to have the url encoded twice ?
(2012-07-10, 12:02)mikebzh44 Wrote: Is there a way to get last added favourites with JSON RPC ?No there is no support for accessing favourites (unless it's somehow possible over the VFS and therefore through JSON-RPC's Files.GetDirectory).
Thanks.
EDIT : I think it's not possible the way some users use favourites :
http://forum.xbmc.org/showthread.php?tid=122448&pid=1144455#pid1144455