(2011-09-28, 17:40)Montellese Wrote:

jasonvp Wrote:Can you please give me an example for "Player.Seek" params (percentage)? It's driving me nuts.

Player.Seek is the best example/usage of the newly supported "union type definition". Player.Seek takes two parameters. The "playerid" (as all the other Player methods do) and a "value" parameter. The "value" parameter can have the following values:

• a number value between 0.0 and 100.0 in which case it is handled as a percentage value to which the player should seek to. So if you pass 50.0 as the value the player will seek to the middle of the file being played.
  
• a string value which takes one of the following values: "smallforward", "smallbackward", "bigforward", "bigbackward". These values replace the old FooPlayer.Small/BigSkipForward/Backward methods that aren't available anymore.
  
• an object containg at least one of the following properties: "hours", "minutes", "seconds", "milliseconds". This allows to define a specific time value to which the player will seek to.
  

Hope this helps.

(2013-11-12, 23:24)calor006 Wrote: Hello,

Could someone give me an example of how to use the specific time value? as opposed to a percentage. I have been all over this page and others, http://wiki.xbmc.org/index.php?title=JSON-RPC_API/v6#Player.Position.Percentage , but to avail.

Thank you for your time.

(2013-05-01, 15:48)Montellese Wrote: Nope there's no custom image resizing yet but it's still on the TODO list.

Here's a more or less up-to-date list of all the changes since the Frodo release: http://forum.xbmc.org/showthread.php?tid=98551&pid=1358657#pid1358657

(2013-11-10, 19:02)Montellese Wrote: Thanks for the detailed description. The problem is not in the webserver but in the way the paths are handled by the texture caching logic. I'll try to get jmarshall to look into it.

(2013-11-06, 18:46)Montellese Wrote: Looking at the code it seems that we throw away filters that contain no or an empty value which could explain this behaviour.

(2013-11-16, 21:12)Tolriq Wrote: Just discovered a strange bug with JSON.

Code:

{"id":1,"jsonrpc":"2.0","method":"VideoLibrary.GetTVShows","params":{"limits":{"start":0,"end":1500},"properties":["episode","genre","rating","originaltitle","studio","year","plot","title","playcount","art","dateadded","mpaa","lastplayed","sorttitle","cast"]}}

Send back playcount field with the actual number episode watched like 92 and field episode contains the actual number of episode so need to substract the values to know the show watched status.

when sending :

Code:

{"id":1,"jsonrpc":"2.0","method":"VideoLibrary.GetTVShows","params":{"limits":{"start":0,"end":1500},"properties":["episode","genre","rating","originaltitle","studio","year","plot","title","playcount","art","dateadded","mpaa","lastplayed","sorttitle"]}}

I.E. same request without cast

Then playcount is sendback as 1 or 0 depending on the actual played status of the show or not.

This is a quite inconsistent behavior leading to some troubles

(2013-11-19, 14:26)Montellese Wrote:

(2013-11-16, 21:12)Tolriq Wrote: Just discovered a strange bug with JSON.

Code:

{"id":1,"jsonrpc":"2.0","method":"VideoLibrary.GetTVShows","params":{"limits":{"start":0,"end":1500},"properties":["episode","genre","rating","originaltitle","studio","year","plot","title","playcount","art","dateadded","mpaa","lastplayed","sorttitle","cast"]}}

Send back playcount field with the actual number episode watched like 92 and field episode contains the actual number of episode so need to substract the values to know the show watched status.

when sending :

Code:

{"id":1,"jsonrpc":"2.0","method":"VideoLibrary.GetTVShows","params":{"limits":{"start":0,"end":1500},"properties":["episode","genre","rating","originaltitle","studio","year","plot","title","playcount","art","dateadded","mpaa","lastplayed","sorttitle"]}}

I.E. same request without cast

Then playcount is sendback as 1 or 0 depending on the actual played status of the show or not.

This is a quite inconsistent behavior leading to some troubles

Thanks for the report. I tracked down the problem but will have to see how best to fix it.

EDIT: Mind creating a bug report on track for it as it's easier to keep track of those than of forum posts.

(2013-11-19, 10:42)MilhouseVH Wrote: Pretty sure this has been introduced sometime since 12/13 Nov - sorry can't be more precise.

(2013-11-19, 10:42)MilhouseVH Wrote: Not sure which commit has caused this, but with a very recent xbmc master (up to and including 93077e6cf0a445ef439e51d54592a3c339873fd9), any call to Files.GetDirectory will result in an unhandled exception:

Code:

08:41:27 T:2852652112   DEBUG: JSONRPC Server: New connection detected
08:41:27 T:2852652112    INFO: JSONRPC Server: New connection added
08:41:27 T:2852652112   DEBUG: JSONRPC: Incoming request: {"id": "libDirectory", "jsonrpc": "2.0", "params": {"directory": "nfs://192.168.0.3/mnt/share/media/Video/TVShows/The Big Bang Theory"}, "method": "Files.GetDirectory", "properties": ["file"]}
08:41:27 T:2852652112   ERROR: Action - thread TCPServer, Unhandled exception caught in thread process, aborting. auto delete: 0
08:41:27 T:2852652112   DEBUG: Thread TCPServer 2852652112 terminating

I've ruled out PR:3671 - still getting unhandled exception without this patch.

Pretty sure this has been introduced sometime since 12/13 Nov - sorry can't be more precise.

(2013-11-20, 07:02)edrikk Wrote: Hi,

I've got a question about player.open which I can't figure out... I have created a few .strm files which point to some ip cameras in the house. I can open the files perfectly fine in XBMC, and they work.

However, these files (although a part of my sources.xml) are not in the library (I don't want them there)... They have been set with a blank 'type'.

I'm wondering if there is a way for me to call player.open giving the api the full path/name of the .strm file to play? This way, I can program remote control keys to jump to the various streams....

Thanks!

(2013-11-20, 08:58)Montellese Wrote: I tried to reproduce this on win32 but it worked fine for me.