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
|
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Mizaki - 2012-04-03 I see there are some PRs which look good. I didn't see anything about playlists. Is that still on your radar? The other thing (which I'll make a feature request for if you think it's doable) is getting the library in small chunks (5, 10 etc. items). As I've mentioned before people with low(er) powered PCs with large libraries can take a long (I'm guessing 15 seconds +) time to retrieve. I guess the DB query is the thing that takes the time so the only way to grab small chunks would be without sorting. Without sorting though it does limit how useful it would be. I'm wondering if you think it's even possible atm? RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - joethefox - 2012-04-04 Hi all, there a remote procedure call to obtain what user has chosen for the "Ignore article when sorting"? Settings>Appearance>File Lists>Ignore article when sorting (e.g. "the") : ON/OFF RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - grywnn - 2012-04-07 Hi there, is it by design that VideoLibrary.getEpisodes prepends season and episode number in the label? For example, GoTs awesome first episode of season two is labeled "The North Remembers", but using JSON i get "label": "2x01. The North Remembers". Which looks pretty odd in listings because my application does its own numbering. I've check my databse: This isn't a scraper issue. Episode names in the database are clear. Nearly forgot: git20120402 PVR build RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - jmarshall - 2012-04-07 Yes, that's by design. Use the title field if you don't want it. The label field is an aggregate field that XBMC sets to a sensible default. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - N3MIS15 - 2012-04-08 Montellese, are you planning on including thumbnail/fanart params to your FooLibrary.Set pull request? If so, are you also planning on making the remote images stored in the database available thru jsonrpc? Also, while on the subject. I have been unable to change a movie set. I can only append, is there a way to replace or remove? Its quite possible im just doing something wrong, im fairly new to coding. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - doozer - 2012-04-09 Hi All, I'm using Playlist.GetItems to pull down the currently queued songs. This is working fine. I just tried doing a similar thing to get a list of queued movies. This also works, but I don't seem to be able to include the "movieid" value in the list. Is there a way to obtain a list of queued movies and their corresponding Library id? Thanks, Matt. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - joethefox - 2012-04-09 Hi, As well as MusicLibrary.GetAlbums where you can filter by artistid or genreid, there is a way to filter by genreid or actorid (castid?) when calling VideoLibrary.GetMovies or VideoLibrary.GetTVShows? Thank you for any answer. RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Mizaki - 2012-04-09 (2012-04-09, 09:15)joethefox Wrote: Hi, http://trac.xbmc.org/ticket/12147 for genreid. castid and castid RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - joethefox - 2012-04-09 thanks for the link, so we just have patience RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Mizaki - 2012-04-09 Yep. I was going to try and do it manually for movies but I did other things instead RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - joethefox - 2012-04-10 (2012-04-09, 22:12)Mizaki Wrote: Yep. I was going to try and do it manually for movies but I did other things instead like patching XBMC JSON API for VideoLibrary.GetMovies? RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Mizaki - 2012-04-10 I wish I could. I do JS badly at best I was just going to take the genre from GetMovies and build the lists from that. UPNP from File.GetDirectory - bradvido88 - 2012-04-11 In previous versions on XBMC (early Eden), when listing upnp:// directories (PlayOn is my upnp server in this example), xbmc would return the http:// path to the file in the "file" field. Previously, i would get a http:// url: Code: http://127.0.0.1:63478/netflix-3fafe162-7ea8-4219-a789-c7367386b9d9/1-netflix-3fafe162-7ea8-4219-a789-c7367386b9d9.mpg In Eden final, I get a upnp:// url Code: upnp://9306789e-2927-4a65-a08d-58a4c8337492/netflix%2d4620b511%2ded24%2d4921%2dae3a%2def450a4a07b3 Here is a sample from the xbmc log where i play a upnp:// path and it resolved it to http:// Code: 09:00:32 T:12672 DEBUG: CApplication::OnKey: return (f00d) pressed, action is Select When I play the upnp:// file in XBMC, I can see from XBMC's log that it resolved the upnp:// path to a http:// path, then plays the http:// file. RE: UPNP from File.GetDirectory - topfs2 - 2012-04-11 (2012-04-11, 15:51)bradvido88 Wrote: In previous versions on XBMC (early Eden), when listing upnp:// directories (PlayOn is my upnp server in this example), xbmc would return the http:// path to the file in the "file" field. Problem with returning http in the file object is due to the fact that in accordance with upnp that path could change so its loosy for a client to cache, the upnp path is much nicer as that forces xbmc to do the lookup and decide what protocol to use (a upnp path could end up in several transport options and we can choose which is best, http, rtsp, samba etc and with several transcoding options). I haven't followed xbmc code closely with upnp but I'm guessing this was an internal url change to allow for scanning upnp stuff into the database (as that had the problem before that the http changed). I'm guessing you want to resolve the upnp url to a http one so you could stream it in your client without going through xbmc? One way to do that would be to actually ask the upnp device about the transports, i.e. you ask it what we ask it. The downside being that you need to be on the same network (which you had to be before too) and that you need to talk upnp (which is actually just xml and http), the biggest problem is that you need to resolve the uuid into an IP, for that you'd need to do an ssdp lookup which requires more than http IIRC. As for letting xbmc doing this resolve I'm not sure if it would be good, one could append different alternative file paths but knowing that they aren't garantued, kindof how upnp does with the transport. Or have a method you can call to xbmc to do that resolve (might be nicer to just do it in the initial file object fetch.) EDIT: I guess I'm saying that you'd need to request that our internal filesystem directory calls provides alternative filepaths to the object, much as how upnp does. That way the jsonrpc could report those also. Not sure if we want to add that to our filesystem or not but could be worth a feature request. Might be nice for addon creators to be able to provide alternatives (as with stream details as quality etc.) RE: UPNP from File.GetDirectory - bradvido88 - 2012-04-11 (2012-04-11, 16:26)topfs2 Wrote: As for letting xbmc doing this resolve I'm not sure if it would be good, one could append different alternative file paths but knowing that they aren't garantued, kindof how upnp does with the transport. Or have a method you can call to xbmc to do that resolve (might be nicer to just do it in the initial file object fetch.) Yes, I agree with what you said about how the http:// urls can change, but I'm trying to track if a particular upnp file has been watched, and XBMC stores watched status based on the http:// file path of the video, not the upnp:// path. So, maybe that it a problem in and of itself for the way XBMC tracks upnp files in its database. Still, it would be very useful to have a resolve method that will use XBMC's internal methods to change the upnp:// path to a tangible video file path (or just do this in the initial file object fetch). |