Jump to content

issue with WebSocket PlayCommand


Recommended Posts

I am seeing an issue with WebSocket PlayNow commands where you use the continue action, they used to have StartPositionTicks in them but now that is missing for continue remote actions.
 

Example PlayNow action that was sent using the Web Client and Resume was selected:

{
u'ItemIds': [31927],
u'PlayCommand': u'PlayNow',
u'ControllingUserId': u'c3d953c03c084d71a8ecbbf9d6e865fc',
u'MediaSourceId': u'038d98dc09bfe329b4e7ec5d1cb7ad6a',
u'AudioStreamIndex': 1,
u'Id': u'ba5c2332dcdbdf7ba86554e0b7471028'
}
Link to post
Share on other sites

I can see 'StartIndex' which is an integer.

 

That might be something to do with playlists since you would expect ticks (long format) not integers.

 

However, under sessions Playing, I can see 'seekPositionTicks'.

 

Perhaps you have to invoke this after 'PlayNow'?

Edited by chef
Link to post
Share on other sites

Yes StartIndex is the playlist item index that you should start playback at.

StartPositionTicks is where in the file you want to start playback.

 

The remote PlayNow command tells the remote client to play something, you have two choices in the interface, resume or play from beginning.

If the user selected resume then the StartPositionTicks lets the remote client know where to start playing from.

 

The work around for me now is to look for StartPositionTicks and if it is there use it otherwise fall back to resume from current position. This looks like it works but is different than how it used to work.

 

@@Luke has this changed or was it always like this?

Edited by TeamB
  • Like 2
Link to post
Share on other sites

 

 

The work around for me now is to look for StartPositionTicks and if it is there use it otherwise fall back to resume from current position. 

 

Ok yes I forgot to mention this during development, but the idea is to make resume the default behavior if no starting position is explicitly defined. In other words, if it's null. Why, because if we require the remote control app to always pass it in, then this creates a dependency on it always having the latest resume position. Most of the time it should, but there are times when it may not.

 

These commands pass through the server without the server really doing much with them. I could probably adjust it to attach the resume position if the starting position is null, but since you're going to have this information, you may as well do the same. If it's null, use the latest resume position.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...