In working with the API, I'm having an issue with Player.Seek. and thee seconds property. I can get several variations of properties working (time, smallforward, bigforward), but using "seconds" is inconsistent. If I pass in seconds that would create an invalid time (negative, or greater than 60), it works, and skips the specified number of seconds, but if the seconds are less than 60, it seeks to that number of seconds overall, not jumping forward by 30 seconds (or whatever)
Here's the json that is sent. If seconds is -30, or 60, or it works, but 30 seconds goes to 30 seconds in the item.
{ "jsonrpc": "2.0", "id": 1, "method": "Player.Seek", "params": { "value": { "seconds": 30 }, "playerid": 1 } }
Is there something I need to fix in the json to make it work consistently?
Maybe this has been broken by the adaptive seeking that has been implemented for Isengard. I'll have to check back with the devs that implemented that feature.
This is on 15.1, and also happens on 15.2. Didn't have an opportunity to try it on an earlier release.
Found this also happens on 14 as well as 16 alpha.
I did a local build and debugged into it. The problem appears to be coming from Check in JSONSchemaTypeDefinition. It appears to be because seconds exists as a stand alone key, but also is in Player.Position.Time. Because Player.Position.Time is the second parameter it checks, it maps seconds onto a Time value when seconds would allow a legitimate time (so < 60 seconds), but if that's not valid, it falls through and maps it to seconds.
I could imagine the easiest fix would be to change seconds to seekseconds, or something that wouldn't cause any ambiguity (or create a new parameter, to avoid breaking already working implementations. :| )
This is still a problem...
FYI, this is STILL a problem even in 18.1 (Leia). I just confirmed the OP's behavior still exists.
Edit: Actually, I've played around with this a bit more. The negative seek works as designed. It's the forward seek that is broken in v18.1. If I set seek > 59 seconds forward, it works as one would expect. If the time is set <60 seconds forward, it sets the current time in the movie to the indicated time. IOW, if I set Seek >59 seconds forward, it skips forward n seconds. However, if I set Seek <60 seconds forward, it moves the movie to that point in time of the movie (e.g. 30 seconds from movie start versus 30 seconds from current time in movie).
I'll submit an official bug report when I have an opportunity to turn on debugging and work with my Kodi box directly, but wanted to post in here FBO others' sanity.
And FWIW, I am accesssing content via shared media server on the same LAN as my (dedicated) Kodi box.
(2019-04-05, 23:23)HTGeek Wrote: [ -> ]FYI, this is STILL a problem even in 18.1 (Leia). I just confirmed the OP's behavior still exists.
Edit: Actually, I've played around with this a bit more. The negative seek works as designed. It's the forward seek that is broken in v18.1. If I set seek > 59 seconds forward, it works as one would expect. If the time is set <60 seconds forward, it sets the current time in the movie to the indicated time. IOW, if I set Seek >59 seconds forward, it skips forward n seconds. However, if I set Seek <60 seconds forward, it moves the movie to that point in time of the movie (e.g. 30 seconds from movie start versus 30 seconds from current time in movie).
I'll submit an official bug report when I have an opportunity to turn on debugging and work with my Kodi box directly, but wanted to post in here FBO others' sanity.
And FWIW, I am accesssing content via shared media server on the same LAN as my (dedicated) Kodi box.
I just confirmed the above in 18.4 for seeks of -10 seconds and 10 seconds. I had to abandon the latter, because it went to the absolute position. I'm only looking at this because the documented Seek(##) Action IDs for use with Input.ExecuteAction don't work, and according to JSONRPC.Introspect, they don't exist.
https://kodi.wiki/view/Action_IDs