+- 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
- Montellese - 2012-01-30
This looks very odd. The webserver should automatically handle all HTTP headers you throw at it (as long as they exist and are valid) independent of whether you use basic authentication or not. One thing that is not correct in your headers is the "Content-Type" which should be "application/json" instead of "application/x-www-form-urlencoded" but that shouldn't make any difference. I just tried with the Advanced Rest Client in Chrome by adding the "Authorization: Basic ..." header field to the (batch) requests and it worked just fine. But I got no clue how the Android sources handle authentication. I have seen some odd behaviour with the official XBMC remote where it always sent every request twice because the first one did not contain the authentication information.
- Tolriq - 2012-01-30
Well I've looked at Official Remote to see what i was doing wrong, and they use another mechanism that is quite broken on some androids that's why i choose the simple header to avoid the double request, since Xbmc http server is not what we can call robust :p
For my problem I've finally found i was not using the exact same code for batch and normal queries ... (Never code without sleep)
The code that works :
Quote: String basicAuth = "Basic "
+ new String(Base64.encode(userpass.getBytes(),
Base64.NO_WRAP));
con.setRequestProperty("Authorization", basicAuth);
userpass is a String containing "user:password"
The one that does not :
Quote: String basicAuth = "Basic "
+ new String(Base64.encode(userpass.getBytes(),
Base64.DEFAULT));
con.setRequestProperty("Authorization", basicAuth);
The doc says :
Quote:NO_WRAP Encoder flag bit to omit all line terminators (i.e., the output will be on one long line).
So it seems that the Base64 encoder just add a simple carriage return and that breaks totally the headers.
Don't know if it's a normal way of acting or a bug in Xbmc that is too sensitive.
- Montellese - 2012-01-30
This is not a bug in XBMC because the HTTP 1.0/1.1 specification defines that the HTTP header ends as soon as there is a single empty line in the data. So if your Base64 encoder adds an extra newline (in addition to the one that will be added by con.setRequestProperty() you will end up with an empty line between the "Authorization" header field and whatever header field comes after that and every HTTP 1.0/1.1 compliant webserver will consider everything after the empty line as part of the request body.
The problem with XBMC's webserver is that it uses libmicrohttpd 0.4.5 because that's the latest version available in all the popular linux repositories. But the development of libmicrohttp is already at version 0.9.x and there were massive changes in between which XBMC can't use as long as the linux repos do not update the version of libmicrohttpd.
- Tolriq - 2012-01-30
Thanks for informations about headers, i just hate android since the bad code works on ICS so they changed something but no one knows :p
Is TCP implementation more robust ? And is there a way out of zeroconf to get the port ? like an http json request ?
I know the port is 9090 and if the users changed it he should now the new port, but since there's no display of it in Xbmc interface, users might forget and it's complexify a lots the settings in remotes.
- Montellese - 2012-01-30
Over TCP you don't have to send a header and there's no authentication but it's more work for the client because you don't get "messages" but a stream so you need to count { and } to know when a JSON-RPC response (or a notification) is complete.
XBMC publishes both the TCP and HTTP port for JSON-RPC over zeroconf (but obviously only if it is enabled in XBMC) but I don't really know anything about zeroconf so I can't help you there.
EDIT: The TCP service is named _XBMC-JSONRPC and the HTTP service is named _XBMC-JSONRPC-H (I know the name sucks but the specification states that the name must not exceed 15 characters). So you can also use zeroconf to get the port of the webserver.
- Tolriq - 2012-01-30
Well the problem about Zeroconf is that is does not work on windows if the users does not have itunes or other apple software to install a dedicated service.
I'll perhaps stick on Http hoping for new microhttpd for next release.
Thanks for answers.
- topfs2 - 2012-01-30
Tolriq Wrote:Well the problem about Zeroconf is that is does not work on windows if the users does not have itunes or other apple software to install a dedicated service.
I'll perhaps stick on Http hoping for new microhttpd for next release.
Thanks for answers.
As for announcing it would be possible to add it as another service in the ssdp announce, would arguably require upnp to be running (unless we seperate ssdp and the mediaserver/mediarenderer part).
Files.GetDirectory lots slower dharma vs eden b2 - zachs - 2012-02-02
Hi,
I notice that Files.GetDirectory (JSON over HTTP) is lots slower in Eden beta 2, compared to the Dharma release -- is that expected to improve before Eden release? Should I file a trac?
For example, running that call on a biggish folder (528 items immediately inside, mostly videos and folders, specifying media=video, no sort, no extra properties) consistently takes over 13 seconds now, whereas in dharma it was consistently sub-second.
Thanks & Regards,
Zach
- Montellese - 2012-02-02
That's because in Dharma you simply got a list of the files (i.e. their filename) and in Eden you get information on whether it's a movie or an episode or whatever and what database ID it has etc. Looking up these values takes extra time (which accumulates when there are so many files in one directory).
- zachs - 2012-02-02
Montellese Wrote:That's because in Dharma you simply got a list of the files (i.e. their filename) and in Eden you get information on whether it's a movie or an episode or whatever and what database ID it has etc. Looking up these values takes extra time (which accumulates when there are so many files in one directory).
Thanks for the response, I can see that being an improvement for many use cases. I just need to get the entire file/folder structure through XBMC, is there a speedier way though XBMC's JSON in Eden? Or via another API in XBMC? I'd need to get files that didn't necessarily get scraped into a Library, so it seems SQL calls are out of the question.
Thanks Again & Kind Regards,
Zach
- Montellese - 2012-02-02
The only way to get around XBMC trying to retrieve the extra information is by setting the "media" parameter to "files" but then you'll get every file in that directory independent of whether it's a video, picture, song or whatever. But it might be faster for you to do that and to the actual video filtering yourself by looking at the extensions. The extensions XBMC uses to filter for videos are
Code:
.m4v|.3g2|.3gp|.nsv|.tp|.ts|.ty|.strm|.pls|.rm|.rmvb|.m3u|.ifo|.mov|.qt|.divx|.xvid|.bivx|.vob|.nrg|.img|.iso|.pva|.wmv|.asf|.asx|.ogm|.m2v|.avi|.bin|.dat|.mpg|.mpeg|.mp4|.mkv|.avc|.vp3|.svq3|.nuv|.viv|.dv|.fli|.flv|.rar|.001|.wpl|.zip|.vdr|.dvr-ms|.xsp|.mts|.m2t|.m2ts|.evo|.ogv|.sdp|.avs|.rec|.url|.pxml|.vc1|.h264|.rcv|.rss|.mpls|.webm|.bdmv|.wtv- zachs - 2012-02-03
Montellese Wrote:The only way to get around XBMC trying to retrieve the extra information is by setting the "media" parameter to "files" but then you'll get every file in that directory independent of whether it's a video, picture, song or whatever. But it might be faster for you to do that and to the actual video filtering yourself by looking at the extensions. The extensions XBMC uses to filter for videos are
Code:.m4v|.3g2|.3gp|.nsv|.tp|.ts|.ty|.strm|.pls|.rm|.rmvb|.m3u|.ifo|.mov|.qt|.divx|.xvid|.bivx|.vob|.nrg|.img|.iso|.pva|.wmv|.asf|.asx|.ogm|.m2v|.avi|.bin|.dat|.mpg|.mpeg|.mp4|.mkv|.avc|.vp3|.svq3|.nuv|.viv|.dv|.fli|.flv|.rar|.001|.wpl|.zip|.vdr|.dvr-ms|.xsp|.mts|.m2t|.m2ts|.evo|.ogv|.sdp|.avs|.rec|.url|.pxml|.vc1|.h264|.rcv|.rss|.mpls|.webm|.bdmv|.wtv
Thank you so much! Back to my sub-second speeds. Great work on Eden, your efforts are much appreciated.
Zach
- AWilco - 2012-02-03
Hang on, 13 seconds to do what I presume is an SQL query? Surely there's something up there. Running 528 separate sql queries? Surely we can streamline that easily. I might take a look at that.
- Montellese - 2012-02-03
Yes it runs at least one query per file it finds so that's at least 528 queries.
- Mizaki - 2012-02-05
I'm pretty sure the answer is "no" but is it possible to get a file scanned for the codec info etc. via JSONRPC?