WebSocket Play call, has it changed?

[TeamB 2438]

@Luke has the WebSocket PlayNow call changed?

It used to when requested on a single item play the item but now it looks like it is sending multiple ID to play, like it is requesting a Play from here sort of action.

Also I noticed that if the the item I am requesting is in progress and I request a Resume the StartPositionTicks is not sent

Example of a Resume request sent from the Web Interface when remote controlling a Kodi client, this was for a single item in a season and it was partially played and I requested "Resume"

EmbyCon.resources.lib.websocket_client|DEBUG|WebSocket Message PlayNow: 
{u'ItemIds': [108273, 108274, 108282], 
u'PlayCommand': u'PlayNow', 
u'SubtitleStreamIndex': -1, 
u'ControllingUserId': u'c3d953c03c084d71a8ecbbf9d6e865fc', 
u'MediaSourceId': u'ac7927a8d8b8f313c2e2a265f89047fd', 
u'AudioStreamIndex': 1, 
u'Id': u'cd1dd24d9c13bfcd911c63bbe95835c6'}

Notice the multiple ItemIds, I only requested a single item to be played.
And there is no StartPositionTicks even though I requetsed a resume:

Has this call changed?

[Luke 42077]

What exactly did you click play on? Was it an episode?

[TeamB 2438]

yes it was an episode.

[TeamB 2438]

@Luke so has the WebSocket data changed?

[TeamB 2438]

@Luke can i get confirmation this is a bug in the server or a change i need to adapt to in the client app

[Luke 42077]

It is likely due to the way that episodes are being auto-queued, but it's not anything new. It's somewhat similar to a music album where if you click on a track, the whole album goes into the queue.

Quote

I request a Resume the StartPositionTicks is not sent

OK yes this is newer. When StartPositionTicks is null, that has been changed to a resume. Essentially, resume unless a specific position of 0 is provided. The benefit of this is that it allows an accurate resume to happen even if the controlling app is not yet aware of the most recent saved resume point.

[TeamB 2438]

@Luke

ok so there are a few changes.

StartPositionTicks is now effectively just a flag, either =0 play from start or "missing" null then let the client resume it by requesting info about the resume position for the client logged in user user.
I guess the issue here is if the user requesting resume is different than the one logged into the client then the client user may have a different resume point to the requesting user and it will play at a different position. That is ok I guess as EmbyCon has no concept of which user requested the item play action remotely and thus will only ever report playback for the client logged in user.

I am still a little confused by the episode play now being a play all action and it does not look like it is play all just play some?

I have a series "Africa" from the BBC, it has 4 episodes, I navigate ALL the way to the first episode:

 

and hit play.

This is what I see in the PlayNow request

{u'ItemIds': [28905, 28906], 
u'PlayCommand': u'PlayNow', 
u'ControllingUserId': u'c3d953c03c084d71a8ecbbf9d6e865fc', 
u'MediaSourceId': u'8195e34cd00b4d5428b934bb85ae23fc', 
u'AudioStreamIndex': 1, 
u'Id': u'cd1dd24d9c13bfcd911c63bbe95835c6', 
u'StartPositionTicks': 0}

Only the first 2 items are in the list, the series has 4 in total

28905 - ep1
28906 - ep2
28907 - ep3
28904 - ep4

So why only 2 and why is it not possible now to play just a single Episode of a show when I request just that episode to play.