Can't read second and subsequent frames from Mobile Server in 2018 R2

We met problem with XProtect 2018 R2 & Mobile Server.

Our web application that use ‘RequestStream’ and post method to read JPEG images does not work.

Problems are

1. We can read only 1st frame. Second and subsequent frame requests are ignored, no response.

2. It seems CloseStream doesn’t work.

Login/acquisition of ConnectonID works in our web application.

Same problem happens in Mobile Playback Sample.

@Yuichi Tsunematsu​ :

Hi Yuichi,

Very strange indeed.

What you are using for your integration ? XPMobileSdk for web ?

Is there anything in the Mobile server log at this time (if there is no response of the request I would expect exception in the log file) ?

How behave the Milestone Web client for the same user and the same camera ?

Is it working okay ?

(I’m trying to find if the problem is in the server or in the sample or in the integration)

Our program written in JavaScript call MobileServerProtocol directly.

We investigate further and find following issues.

1. This problem happens all 2018 R2 Mobile Server

2. “CloseStream doesn’t work.” was our program mistake, not a bug.

3. It seems “Speed” setting in RequestStream command doesn’t work correctly from 2018 R2.

About last issue, we confirm following symptom.

[NG case - Can’t read second and subsequent frames]

1. Connect

2. Login

3. RequestStream and set Speed parameter as 1

4. Read frames

[OK case - Can read all frames]

1. Connect

2. Login

3. RequestStream and set Speed parameter as 1

4. ChangeStream and set Speed parameter as 1

5. Read frames

So we think our problem is caused by disfunction of Speed parameter setting in RequestStream.

We’d like to know this is a bug or specification.

Plus we’d like to confirm additional ‘ChangeStream’ call is OK in case this symptom is a bug.

Hi Yuichi,

The described workflow (“OK case”) is okay and this is the intended way of use.

Actually this is the way how is used in the Milestone Mobile and Web clients.

If you call ChangeSrteam after RequestStream, you could omit “Speed” parameter in the RequestStream command.

In order to track why the “NG case” is not working could you please:

  1. Sniff and print what is the actual XML send to the server.

  2. Look at the Playback Status Flags available in the video channel.

They indicate what is the status of the playback (Playing forward, Playing backward or stopped).

Btw. Why don’t you use the JS SDK (Milestone Mobile SDK) ?

> 1) Sniff and print what is the actual XML send to the server.

Please refer attached text file.

> 2) Look at the Playback Status Flags available in the video channel.

OK case : 2

NG case : 16

> Why don’t you use the JS SDK (Milestone Mobile SDK) ?

Because there was not JS SDK at the timing we developed web UI.

Hi Yuichi,

I’ve checked the server behavior when speed parameter is added on the RequestStream command.

It seems we introduced a issue and now it is not working.

Please use the described upper workflow - calling additionally ChangeStream after creation of the stream.

It is very strange playback status flag to have value of 16. It means DB start. By default however stream should be placed at DB end. I’ve created a internal issue to be investigated.

I got it. Hope this problem be fixed in future XProtect release.