+- 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
- pilluli - 2011-11-14
Montellese Wrote:That's what you'll have to do for now.
Thanks for the quick response Montellese, I will keep doing that then. The only problem I see is that the query takes 3 seconds (to retrieve my entire videos collection and it is not that big) and was looking for ways to reduce that time...
Again, thanks!
- Montellese - 2011-11-14
pilluli Wrote:Thanks for the quick response Montellese, I will keep doing that then. The only problem I see is that the query takes 3 seconds (to retrieve my entire videos collection and it is not that big) and was looking for ways to reduce that time...
Again, thanks!
Yeah the problem is that retrieving the "resume" property requires two extra queries for every item retrieved. So if you retrieve 100 movies that makes 100 * 2 + 1 query compared to 1 query if you don't retrieve the "resume" property.
That's why it takes so long. Obviously pre-filtering will reduce the number of queries but as I already said that's not possible right now (but it is a planned feature).
- dwagner - 2011-11-14
I'm wondering if anybody else has run into this problem.
If I send to the JSON Api (via TCP) two or more requests right away (i.e. before the first one has had a chance to respond), more then likely I will then receive all the responses together as one piece of data. The standard JSON parsers on iOS will then complain that there is garbage after the end of the object.
- Montellese - 2011-11-14
dwagner Wrote:I'm wondering if anybody else has run into this problem.
If I send to the JSON Api (via TCP) two or more requests right away (i.e. before the first one has had a chance to respond), more then likely I will then receive all the responses together as one piece of data. The standard JSON parsers on iOS will then complain that there is garbage after the end of the object.
Is this over TCP or HTTP?
Over TCP this is perfectly valid. Theoretically you can't even assume that the order of the responses is the same as the order of the requests (neither over TCP nor HTTP). That's why you have to provide the "id" in every request.
- dwagner - 2011-11-14
Montellese Wrote:Over TCP this is perfectly valid. Theoretically you can't even assume that the order of the responses is the same as the order of the requests (neither over TCP nor HTTP). That's why you have to provide the "id" in every request.
I figured as much, I just wanted to see if anybody had an elegant solution because both the built in iOS parser and the JSON framework fail when you send the data in, rather then parsing one object and giving you an offset to use for the next. The only solution off the top of my head requires me to manually parse the data first to separate the objects before sending them to the parser. Seems like it defeats the purpose of using a JSON parser a bit.
Thanks for the extra information about the ordering. Is the ordering only not guaranteed for responses, or also for execution order. The reason this is important is that currently to resume we send two commands. If order is not guaranteed then technically we have to wait for playing to commence before sending the seek command. Do-able but a bit of a pain.
- Montellese - 2011-11-14
Currently there is no parallelism or anything and every request is stalled until the previous request has been finished but in the future we are planning to handle requests in seperate threads. This makes it possible to execute fast requests while slow requests are still being processed (e.g. calling JSONRPC.Ping while VideoLibrary.GetMovies returns 1000+ movies etc).
So if you want to be on the safe side (i.e. future proof) you need to wait till you got the response for the Player.Open request before sending the Player.Seek request. The JSON-RPC 2.0 specification states that it is not required to keep the order of requests even in batch requests.
For the particular case of resuming playback I am planning to add a "options" parameter to Player.Open which will allow to specify a resume point.
- Montellese - 2011-11-15
grywnn Wrote:Me againFinally got around to fix this bug in https://github.com/xbmc/xbmc/commit/d187b1c2197c4477ba22f5364a3044cc1be46045 so it should now behave as you expect it to.
Bug?
When i use Playlist.Swap and the position of the currently playing item changes, Player.getProperties doesn't reflect the changes afterwards.
Example:
Currently playing item 2 of playlist 0.
Now i swap item 1 and 2.
The item formerly known as item 2 continues to play, but is now on position 1.
But Player.getProperties will still return position 2.
This goes as far that even the music playlist on XBMCs screen reflects the swap, but highlights the wrong track.
- grywnn - 2011-11-15
Montellese Wrote:Finally got around to fix this bug in https://github.com/xbmc/xbmc/commit/d187b1c2197c4477ba22f5364a3044cc1be46045 so it should now behave as you expect it to.Thanks a ton, will test and report tomorrow.
- jimk72 - 2011-11-16
dwagner Wrote:I'm wondering if anybody else has run into this problem.
If I send to the JSON Api (via TCP) two or more requests right away (i.e. before the first one has had a chance to respond), more then likely I will then receive all the responses together as one piece of data. The standard JSON parsers on iOS will then complain that there is garbage after the end of the object.
I was having all kinds of problems like this with tcp. also had large requests(all artist, ect..) would be sent back in random chunks. I ended up switching over to http post ect.. that way I get the full response and it is only that response and then use the tcp to monitor for notifications. Most of them are very short so a custom parser to make sure it is only one notification was easy. All my problems related to JSON ended after that
- Blacksheep70 - 2011-11-16
A method to query if XBMC is currently idle (TRUE|FALSE) would be useful.
E.g. to trigger special actions or maintenance on smaller machines when there is no media playing.
I personally would use this method to shut down the system automatically after the system was brought up automatically (to record TV) via ACPI wakeup if no media is currently playing.
Regards,
Blacksheep
- neoflex - 2011-11-16
Hi and sorry if this question has already been asked before.
I hope I am wrong but it seems that there is no method in the JSON Api to get the list of audio playlists in the audio library. Something like AudioLibrary.GetPlaylists ?
If it is the case, do you have plan to add this in the near future ?
(if not I might give it a try but that could results in some ugly code :p)
- rossmohax - 2011-11-16
Right now neiher JSON nor HTTP api interface have feature to manually update DM. As if you added new video, then tries get its info and parser cannot recognise its name, then it ask you to enter name of video and then queries IMDB with that name. Right no to do that I have to have keyboard attached to linux box.
I checked the code and it seems that there is no ready-made function which can be called from RPC handler, all "manual editing" of item name is done in GUI code.
But it would be nice to have such option.
- jimk72 - 2011-11-16
neoflex Wrote:Hi and sorry if this question has already been asked before.
I hope I am wrong but it seems that there is no method in the JSON Api to get the list of audio playlists in the audio library. Something like AudioLibrary.GetPlaylists ?
If it is the case, do you have plan to add this in the near future ?
(if not I might give it a try but that could results in some ugly code :p)
I access the directory the playlists are stored in and parse them. When one is selected I send each song from the list to xbmc using add to playlist then play that playlist. Works good for now.
- neoflex - 2011-11-16
jimk72 Wrote:I access the directory the playlists are stored in and parse them. When one is selected I send each song from the list to xbmc using add to playlist then play that playlist. Works good for now.
Thanks for the tip. I was looking for a more integrated solution to also integrate playlists from spotify but I can use a mix between both approaches maybe. Music playlists can be acceded through the http://***.***.***.***:8082/vfs/special://musicplaylists/***.m3u URL right ? but how can you get a listing of the files there ?
- Montellese - 2011-11-16
neoflex Wrote:Thanks for the tip. I was looking for a more integrated solution to also integrate playlists from spotify but I can use a mix between both approaches maybe. Music playlists can be acceded through the http://***.***.***.***:8082/vfs/special://musicplaylists/***.m3u URL right ? but how can you get a listing of the files there ?
Files.GetDirectory is what you are looking for if you wanna do the workaround.
FooLibrary.GetPlaylists() will be added as soon as it will be possible to load m3u (and other file based) playlists into the Playlist namespace but that's not gonna happen for Eden.