+- 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
- jasonvp - 2011-09-30
Hi Montellese,
Are there any plans for more discrete navigation control of the GUI?
For example currently there is Input Home etc. What about Input Weather, Pictures, Videos, Music, Programs, System and their Sub Folders?
Cheers
Jason
- Montellese - 2011-09-30
jasonvp Wrote:Are there any plans for more discrete navigation control of the GUI?
For example currently there is Input Home etc. What about Input Weather, Pictures, Videos, Music, Programs, System and their Sub Folders?
I'm not sure as in some skins entering the Videos section (or any other of the main sections) without going through the home screen messes with the logic and design. Furthermore subfolders are partly skin-dependant as well so it would be difficult to get it right on every skin.
- jasonvp - 2011-09-30
Montellese Wrote:I'm not sure as in some skins entering the Videos section (or any other of the main sections) without going through the home screen messes with the logic and design. Furthermore subfolders are partly skin-dependant as well so it would be difficult to get it right on every skin.
I haven't checked out the other skins because I wasn't sure if they worked with the nightly builds. I'll check them out.
Cheers
Jason
- el_Paraguayo - 2011-10-05
I've come across a problem.
I was previously running nightly version (20110827-639950e) on Windows and wrote a script to play a random movie.
The script had the following JSON request:
Code:
{"jsonrpc": "2.0", "method": "VideoLibrary.GetMovies", "params": { "fields": ["genre", "playcount", "file"]}, "id": 1}However this request no longer works. I don't know at which version the request stopped however I have just downloaded version (20111005-fc24dcb) and confirm the request doesn't work.
The response I receive is:
Code:
{"error":{"code":-32602,"data":{"message":"Too many parameters","method":"VideoLibrary.GetMovies"},"message":"Invalid params."},"id":1,"jsonrpc":"2.0"}Has something changed in the protocol that means my request is now invalid?
If so, can someone point me in the direction of a solution?
Many thanks,
el_P
- Martijn - 2011-10-05
Think the
"fields" must be changed to: "properties"
At least that what i saw in some script changes to fix this problem.
Code:
{"jsonrpc": "2.0", "method": "VideoLibrary.GetMovies", "params": { "properties": ["genre", "playcount", "file"]}, "id": 1}- Montellese - 2011-10-05
Machine-Sanctum Wrote:Think the
"fields" must be changed to: "properties"
At least that what i saw in some script changes to fix this problem.
Code:{"jsonrpc": "2.0", "method": "VideoLibrary.GetMovies", "params": { "properties": ["genre", "playcount", "file"]}, "id": 1}
Correct.
- Montellese - 2011-10-05
Probably the last real change to the jsonrpc API for Eden:
Wednesday, October 5th 2011:
Commit: 288f4967d954769282fc
- Added GetItem to the Player namespace to retrieve the currently playing item (also works for items played with Player.Open or from recently added script)
This should make it easier for 3rd party apps to easily retrieve the currently playing item. You still need the "playerid" though but you don't have to call Player.GetProperties and Playlist.GetItems as well to retrieve all the information about the currently playing item.
Furthermore this does also work for items being played without them being part of any playlist (like it currently is when you start an item with Player.Open or if you start a movie from recently added in XBMC GUI). So for now Player.GetItem is the most fool-proof way to retrieve information about the currently playing item.
- joshua.lyon - 2011-10-05
Montellese Wrote:Pay special notice to the last change as it will probably affect every client/app using jsonrpc:
Tuesday, September 20th 2011:
Commits: a03c34b37ae64637a9fd, 2a848458dbfd36d87058, 481a6007e899bdba21f2
- Renamed "fields" parameters to "properties" parameters
I noticed that in a previous post you mentioned that the team was looking at this as a good point in time to draw a line in the sand and basically say that the JSON API is different between XBMC 10 and 11 [paraphrased].
As noted in the quoted post, the change from 'fields' to 'properties' basically breaks any jsonRPC app that's requesting library data. I'm just curious why the team decided not to maintain backwards compatibility (especially on that item)... or why even make the change from 'fields' to 'properties' in the first place?
Up until that change, I've been able to maintain compatibility between Dharma and Eden without having to maintain major logic for different versions. While it's not a huge pain, app developers now have to maintain logic that determines the XBMC version and then issues specific requests accordingly.
- el_Paraguayo - 2011-10-05
Machine-Sanctum Wrote:Think the
"fields" must be changed to: "properties"
At least that what i saw in some script changes to fix this problem.
Code:{"jsonrpc": "2.0", "method": "VideoLibrary.GetMovies", "params": { "properties": ["genre", "playcount", "file"]}, "id": 1}
Works perfectly. Thank you.
- topfs2 - 2011-10-06
joshua.lyon Wrote:As noted in the quoted post, the change from 'fields' to 'properties' basically breaks any jsonRPC app that's requesting library data. I'm just curious why the team decided not to maintain backwards compatibility (especially on that item)... or why even make the change from 'fields' to 'properties' in the first place?
Up until that change, I've been able to maintain compatibility between Dharma and Eden without having to maintain major logic for different versions. While it's not a huge pain, app developers now have to maintain logic that determines the XBMC version and then issues specific requests accordingly.
The API is far from backwards compat already in the move from v2 -> v4 (even if not great changes), thus we decided that we might aswell do ALL non-backwards compat changes which has bugged us. This to make less changes (perhaps even keep backwards compat) in the next upcomming versions.
The naming of fields was a bit of a mistake in the beginning, it was used to reference the likeness to a database. The rest of the termology of xbmc is "properties" which sounds much nicer, so we thought if we are breaking backwards compat now we might aswell change that also, as we will never be able to do that later
EDIT: Also you all should consider v2 (dharma) to have been just a taste of whats to come, it was never really finished and was mostly added as a showcase. Eden (v4) is looking rather finished and polished. While we have lots of ideas for the future it is very cleaned out and should be maintainable.
- Montellese - 2011-10-06
joshua.lyon Wrote:I noticed that in a previous post you mentioned that the team was looking at this as a good point in time to draw a line in the sand and basically say that the JSON API is different between XBMC 10 and 11 [paraphrased].Absolutely correct.
joshua.lyon Wrote:As noted in the quoted post, the change from 'fields' to 'properties' basically breaks any jsonRPC app that's requesting library data. I'm just curious why the team decided not to maintain backwards compatibility (especially on that item)... or why even make the change from 'fields' to 'properties' in the first place?You gave the answer to the backwards compatibility yourself in the first paragraph. I had to make soo many changes to our jsonrpc implementation and API just to make it JSON-RPC 2.0 compliant that we already had to give up on backwards compatibility just to follow the specification.
joshua.lyon Wrote:Up until that change, I've been able to maintain compatibility between Dharma and Eden without having to maintain major logic for different versions. While it's not a huge pain, app developers now have to maintain logic that determines the XBMC version and then issues specific requests accordingly.That only holds true for the AudioLibrary, VideoLibrary and Files namespaces. All the other namespaces have undergone drastic changes:
- AudioPlayer, VideoPlayer and PicturePlayer have all been merged to Player
- AudioPlaylist, VideoPlaylist and Playlist have all been merged to Playlist
- Some methods in JSONRPC namespace have been renamed
- Most methods in XBMC namespace have either been removed or moved to a different namespace (Application namely)
As you can see we already had to break backwards compatibility for all those namespaces just to get a clean API on which we can build in the future without having to break backwards compatibility again.
The main reasons for renaming "fields" to "properties" was that
1. in our opinion (topfs2, ronie and me) "properties" is a better describing name than "fields" for the properties of a media item ("fields" sounds so database-ish)
2. with the introduction of GetProperties methods (which take a "properties" parameter to retrieve needed properties) in the System, XBMC, Playlist and Player namespace renaming "fields" to "properties" helped to achieve a uniform naming of parameters across methods and namespaces.
- jasonvp - 2011-10-06
Montellese Wrote:Probably the last real change to the jsonrpc API for Eden:
Tuesday, September 20th 2011:
Commit: 288f4967d954769282fc
- Added GetItem to the Player namespace to retrieve the currently playing item (also works for items played with Player.Open or from recently added script)
This should make it easier for 3rd party apps to easily retrieve the currently playing item. You still need the "playerid" though but you don't have to call Player.GetProperties and Playlist.GetItems as well to retrieve all the information about the currently playing item.
Furthermore this does also work for items being played without them being part of any playlist (like it currently is when you start an item with Player.Open or if you start a movie from recently added in XBMC GUI). So for now Player.GetItem is the most fool-proof way to retrieve information about the currently playing item.
Hi Montellese,
Player.GetItem is not in the Introspect. Did you forget?
GIT:20111005-fc24dcb
Cheers
Jason
- Montellese - 2011-10-06
jasonvp Wrote:Hi Montellese,
Player.GetItem is not in the Introspect. Did you forget?
GIT:20111005-fc24dcb
Nope I didn't forget it, the commit just didn't make it into the nightly build from yesterday (2011-10-05). If a method doesn't show up in introspect it cannot be called at all because XBMC itself uses the introspect as well to determine whether a request is calling a valid/existing method.
- jasonvp - 2011-10-06
Montellese Wrote:Nope I didn't forget it, the commit just didn't make it into the nightly build from yesterday (2011-10-05). If a method doesn't show up in introspect it cannot be called at all because XBMC itself uses the introspect as well to determine whether a request is calling a valid/existing method.
Oh! Sorry about that.
- el_Paraguayo - 2011-10-06
Can the VideoPlaylist.GetItems method be used to get a list of videos in a specified playlist? or does it only return videos in the current active playlist?