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
|
- carmenm - 2011-04-04 i just tested the tcp Notification system and i think is great. Two things though: - I think that it would be great to send a playing/paused status report when a client connects to XBMC and XBMC is playing. That would prevent form having to ask and we would be sure to have the good state when connecting. - When i stop playing a movie i get a notification Quote:{"jsonrpc":"2.0","method":"Announcement","params":{"data":{"movieid":12,"speed":1},"message":"PlaybackSpeedChanged","sender":"xbmc"}}is that normal? THanks - topfs2 - 2011-04-04 While it is arguably nice to get the state on connect its hard to justify it being sent. Its not really xbmc's job to make sure the state is correct at the client, i.e. xbmc doesn't necessarily know what the client wants. For example say you make a client which allows you to manipulate the library but handles nothing playback worthy, is it sane sending that even then, how can xbmc know this. What initial states should we send, if playback then it might make sense making sure that the library state is correct, which essentially means sending every item id in the library. As you see from these examples its not possible really. If xbmc knew what states the client is indeed interested in then yes, we could. but it may need a redesign of the API, for very little benefit. Most RPC's out there assumes that the client gets the initial states afaik. - carmenm - 2011-04-04 topfs2 Wrote:For example say you make a client which allows you to manipulate the library but handles nothing playback worthy, is it sane sending that even then, how can xbmc know this.But you send it to any client when play state changes. You dont let the client ask for it! To me if you notify the client of state change, you should first notify it of the initial state. But it s not a big deal for me . - topfs2 - 2011-04-04 Well we send only state changes, which is by far less bandwith in the library case. And atm we do set those on by default for easy development, that might change at some point. - Montellese - 2011-04-04 carmenm Wrote:But you send it to any client when play state changes. You dont let the client ask for it! You can use JSONRPC.SetAnnouncementFlags() to tell XBMC which notifications you would like to receive. But (according to the specification) notifications/announcements are something every client receives and not something you send to only one connected client. So you should not send a notification to a single (newly connected) client anyway because you'd have to send it to every client available. - carmenm - 2011-04-04 @Montellese: ok i get the way it works for Notifications. My state machine will ask for playing state on connection. Thanks for taking the time to explain. - carmenm - 2011-04-05 Montellese Wrote:First call "Player.GetActivePlayers" to determine the currently active player (audio, video or picture). If it is audio or video call Audio/VideoPlaylist.GetItems and read the "current" field to get the position of the currently playling item in the playlist. The "items" field contains an array of all items in the playlist and "items[current]" is the currently playing file. You can also tell jsonrpc which fields to return for every item in the playlist and therefore you'll have all the information you need. finally had the time to test this. It works great expect that most fields i ask for are not returned. For example tagline, season, episode, imdbnumber, runtime. In fact movieid would be enough but i cant get this one either. I tried to create an issue on trac but didnt find where to register will try again tomorrow. - Montellese - 2011-04-05 Everyone interested in JSON RPC please read http://forum.xbmc.org/showthread.php?p=767487 carefully. - ppic - 2011-04-05 thanks for the infos - Kabooga - 2011-04-05 Thank you for the hard work. Been waiting for this Cheers. - carmenm - 2011-04-05 Great. You did an amazing job! - carmenm - 2011-04-05 i am now playing with the new json. It is really really great! I especially love the new introspect and the error responses!!! Now time for the questions: -VideoPlaylist.GetItems : is there a way to get the Library.Id if there is one? That could be very useful if we then want to do something like VideoLibrary.GetMovieDetails -about sending multiple request a the same time. If i take the example of VideoLibrary.GetMovies and VideoLibrary.GetTVShows. WOuld it make responses time shorter if sending both at the same time ( i am taking that example as i suppose they access the database, and that you say in introspect that cast and set may make response time longer) Thanks a lot for that big update. It helps a lot while developing. - topfs2 - 2011-04-05 carmenm Wrote:i am now playing with the new json. It is really really great! If you send two requests at the same time they will be done in sync, they will have less overhead (as you only have one httpheader for both requests). So it depends a bit on your needs. For example the webserver can execute more than one request at a time so if you send A which takes 1 minute and B which takes 30 s, doing that in sync will take 1min and 30s. if you send them seperate with extra overhead it will take roughly 1 min in total for both. So consider it as transactions in normal databases, if you need them to be in sync use that feature, otherwise you can do them at the same time. As said, if overhead is an concern it can also be useful (getmovies + gettvshows return so much data overhead is of no concern). Say you want time of playback you can bundle that in with something else as the return is almost the same as the overhead probably - carmenm - 2011-04-05 ok i get it. I see the point of no use for Getmovies or gettvshows now. I also get the idea of something like playback time at the same time as something else. i just dont know how to implement it on my side A remark on getPlaylistItems. WIth the new version all fields return something. But some fields are empty for tvshows even if the info exists on xbmc. It happens for runtime, rating, tagline, genre Do i add a bug for that? Thanlks - Montellese - 2011-04-05 carmenm Wrote:A remark on getPlaylistItems. WIth the new version all fields return something. But some fields are empty for tvshows even if the info exists on xbmc. Do you mean info of tv episodes? Because a playlist item can not be a tv show, but only a tv episode. "genre" and "tagline" are no valid fields for a tv episode but "runtime" and "rating" are. Please create a bug ticket so I don't forget about it. EDIT: I just tested it and it works fine for me. For some reason I get an empty string for "runtime" but that also happens when calling VideoLibrary.GetEpisodes. The "rating" values show fine on VideoPlaylist.GetItems for me. |