[Tolriq]

Well the point is that you can't pass json directly to /image you need to urlencode it again.
This lead to url like : http://192.168.0.11:90/image/image://Z%2...cmovie.tbn

urlencoding the % to %25 is really not needed but without it doesn't work.

At the moment the option to get image is :
- http://xxx:yy/image/ urlencode the json image path
- http://xxx:yy/vfs/ json image path without "image://" (no url encode)


Seems to be the opposite from what jmarshall says in the last post.

For me the /image should not need the second url encode or the json should be url encoded but there's something not logical.

Edit : After more tests /vfs/image:// works with correct urlencoding.

[Montellese]

OK I was wrong in my previous statement. You have to URL-encode the thumbnail/fanart URL again BUT you have to URL-encode the whole URL not just what comes after "image://" so the above URL you posted is invalid because it contains "://" unencoded (which is reserved for appearing after the protocol). That's also probably why it didn't work for you over VFS. So what you should do is grab the whole URL JSON-RPC provides, URL encode it and either append it to "http://<ip>:<port>/vfs/" or to "http://<ip>:<port>/image/".

As an example JSON-RPC provides

Code:

image://H%3a%5c12%20Rounds%5c12%20Rounds.tbn

as the thumbnail URL for "12 Rounds". You take that URL and have to URL-encode it again (because of the "://" in there). That results in

Code:

image%3A%2F%2FH%253a%255c12%2520Rounds%255c12%2520Rounds.tbn

which you can use either like

Code:

http://<ip>:<port>/vfs/image%3A%2F%2FH%253a%255c12%2520Rounds%255c12%2520Rounds.tbn

or

Code:

http://<ip>:<port>/image/image%3A%2F%2FH%253a%255c12%2520Rounds%255c12%2520Rounds.tbn

At least that's how it works for me.

When using the image/ handler you can also just take whatever JSON-RPC provides, remove the "image://" from the beginning of the URL and append the rest to http://<ip>:<port>/image/ which would lead to

Code:

http://<ip>:<port>/image/H%3a%5c12%20Rounds%5c12%20Rounds.tbn

[Tolriq]

Hum ok that seems more logical And effectively works like that. (Was also the reason about problem of /vfs)

I was just a little lost with docs in this post that may not be always up2date.

Thanks for clarification.

[Montellese]

Wednesday, July 11th 2012:
Commit: c924204d75d511489972

• added SendText, ExecuteAction, ShowOSD and ShowCodec to Input namespace
  
• added Input.OnInputRequested and Input.OnInputFinished notifications which are sent when the virtual keyboard (or the numerics/date/time/ip) dialog is activated/deactivated.
  

[Millencolin007]

Wednesday, July 11th 2012:
Commit: c924204d75d511489972

• added SendText, ExecuteAction, ShowOSD and ShowCodec to Input namespace
  
• added Input.OnInputRequested and Input.OnInputFinished notifications which are sent when the virtual keyboard (or the numerics/date/time/ip) dialog is activated/deactivated.
  

The virtual keyboard is often used to edit an existing text. Would it be possible to include this text in the Input.OnInputRequested notification?

[Montellese]

This has already been requested but after I added the new features. It will be added ASAP.

[Millencolin007]

Requesting song details does not return the artistid in the current git builds. In eden the same request works ok.

Request

Code:

{
    "id": 1,
    "jsonrpc": "2.0",
    "method": "AudioLibrary.GetSongDetails",
    "params": {
        "properties": [
            "title",
            "artist",
            "albumartist",
            "genre",
            "year",
            "rating",
            "album",
            "track",
            "duration",
            "comment",
            "lyrics",
            "musicbrainztrackid",
            "musicbrainzartistid",
            "musicbrainzalbumid",
            "musicbrainzalbumartistid",
            "playcount",
            "fanart",
            "thumbnail",
            "file",
            "artistid",
            "albumid"
        ],
        "songid": 65
    }
}

Response

Code:

{
    "id": 1,
    "jsonrpc": "2.0",
    "result": {
        "songdetails": {
            "album": "Best Club Electro House",
            "albumartist": "",
            "albumid": 10,
            "artist": "Acapulco",
            "comment": "",
            "duration": 414,
            "fanart": "image://",
            "genre": "House",
            "label": "Nous Allons Danser  Le Club",
            "lyrics": "",
            "musicbrainzalbumartistid": "",
            "musicbrainzalbumid": "",
            "musicbrainzartistid": "",
            "musicbrainztrackid": "",
            "playcount": 0,
            "rating": 4,
            "songid": 65,
            "thumbnail": "",
            "title": "Nous Allons Danser  Le Club",
            "track": 1,
            "year": 2004
        }
    }
}

[jmarshall]

This is a known issue - there's a pull request for it here: https://github.com/xbmc/xbmc/pull/1117

[Mizaki]

Can't seem to make FR on trac any more so I'll put it here for now. If I'm supposed to do something else let me know

Notification for library clean - start and stop
Notification for library export - start and stop

This may be a silly question/idea but is it possible to provide a UPnP link for library items? I'm thinking with the headless it might be useful. You'd probably want to use a proper UPnP program to browse the library but if possible it might be useful.

[Montellese]

Yeah feature requests have been disabled on trac. You can create an issue and label it as "Feature Request" on my github issues page (see https://github.com/Montellese/xbmc/issues) if you want.

What do you mean with UPnP link? I never really used UPnP so far and AFAIK the UPnP implementation in XBMC is being reworked as part of alcohecas GSoC project.

[Millencolin007]

Such a UPnP link would be fantastic since it would let us stream files and more importantly seek inside a file from a remote location using an url provided by json-rpc, something which does not work with the "vfs" url which is returned by Files.PrepareDownload (since it does ignore partial http requests)

[Mizaki]

Yeah feature requests have been disabled on trac. You can create an issue and label it as "Feature Request" on my github issues page (see https://github.com/Montellese/xbmc/issues) if you want.

What do you mean with UPnP link? I never really used UPnP so far and AFAIK the UPnP implementation in XBMC is being reworked as part of alcohecas GSoC project.

I've added the FR to your issues. Shall I add the other outstanding ones or are they alright where they are?

I'm somewhat in the dark about UPnP as well. Maybe Millencolin007 can explain things better. If I look at an item in Windows Media Player via UPnP I see the link:

Code:

http://xbmc:58520/%2525/%252Fmnt%252Fthings%252Ffilms%252F2%2520Fast%25202%2520Furious.avi?WMContentFeatures=DLNA.ORG_PN=AVI;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01000000000000000000000000000000&WMHME=1&WMQ=1&WMHMETitle=MgAgAEYAYQBzAHQAIAAyACAARgB1AHIAaQBvAHUAcwA=

I'm thinking with a headless XBMC I could then pass that on to a player.

[Millencolin007]

I am not familiar with the upnp protocol neither. I just had a look at a network trace myself. Streaming from one xbmc instance to another I get something like the following url. The problem is that the url is not persistent as it is not valid anymore when xbmc is restarted.

Code:

http://xbmc:55001/%2525/80D45637116C76376F873DC092217A23%252F12%2520-%2520Alain%2520Souchon%2520-%2520C'est%2520d%25C3%25A9j%25C3%25A0%2520%25C3%25A7a.mp3

BTW: I think that we already get a http url using json-rpc Files.PrepareDownload which could be used to send to a Upnp Renderer. The problem is that the xbmc webserver does not support partial http requests (whereas the upnp lib from xbmc does) which prevents seeking inside a file.

[gertjanzwartjes]

I was testing out pre-Frodo builds on OS X. I have a test library with ~900 (fake) movies in it. When I do a simple

Code:

VideoLibrary.GetMovies

without any special properties or whatsoever, my MacBook's fans start blowing and there's no response, XBMC actually crashes before it can finish its response.

I saw some chatter in this topic about slow movie queries; is this a known issue still? The library + request works perfectly fine on both Dharma and Eden.

Just wanted to check if I might be doing something stupid. Thanks guys, lot's of interesting and useful new stuff coming into the JSON-RPC interface for Frodo! Keep up the good work!

[Montellese]

There seems to be an issue with JSON-RPC and OSX but I have no clue what the problem is. I can only test on win32 and linux and at least on win32 JSON-RPC requests are faster in Frodo than they are in Eden. Haven't done any comparisons on linux. Furthermore there's no platform specific code in JSON-RPC so the only place where the problem could be located is the webserver. Will have to find someone on the team to help me debug this on OSX.