TeamB 2352 Posted November 24, 2019 Share Posted November 24, 2019 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 comment Share on other sites More sharing options...
chef 3745 Posted November 24, 2019 Share Posted November 24, 2019 (edited) 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 November 24, 2019 by chef Link to comment Share on other sites More sharing options...
TeamB 2352 Posted November 24, 2019 Author Share Posted November 24, 2019 (edited) 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 November 24, 2019 by TeamB 2 Link to comment Share on other sites More sharing options...
Luke 37049 Posted November 25, 2019 Share Posted November 25, 2019 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 comment Share on other sites More sharing options...
TeamB 2352 Posted November 25, 2019 Author Share Posted November 25, 2019 ok cool thanks for confirming and explaining. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now