We have confirmed that the same issue (where VOD is limited to 1 fps) also occurs with XProtect Professional+ 2025 R2 and WebRTC JavaScript (2025 R2).
For your reference, we tested with two versions of the browser (Chrome), 132 (2025/1) and 137 (2025/6), but the issue did not change. In other words, it is not caused by a change in the browser version.
As this matter is urgent, we would appreciate it if you could provide a response, even if it is just a progress update.
I’ve conducted tests in the Milestone test labs and observed results that are consistent with or similar to your findings. I’ve now escalated the issue to Milestone Development for further investigation. I’ll provide updates here as soon as additional information becomes available.
We encountered a similar problem when working with Web.
We use Web Client 2023 R2 (VMS XProtect Professional Plus 2023R2).
When receiving a set of images from the specified server using mipsdkmobile-web for the corresponding server version (https://github.com/milestonesys/mipsdkmobile-web), the retrieval of archived video (in the form of a set of images) is slow (as is the case when working in the XProtect® Web Client 2023 R2 interface), while receiving live video occurs without delay.
Question: How can we configure the Milestone system so that the delivery of video archives via mipsdkmobile-web occurs without delay?
I would like to report on the subsequent situation.
Until around 18:00 on 8/29, it was in a 1fps state.
After that, I did not access the system, but when I accessed it again around 14:00 on 9/4, the issue had been resolved. All three environments where the issue had occurred (two actual machines, one AWS) were resolved.
No particular settings were changed (although some machines were restarted).
When playing back data from August, when the 1fps issue occurred, it still plays back at 1fps. (As mentioned before, playback with the Smart Client displays at 15fps.)
Thank you for reporting this, I hope that the analysis will explain this. As I mentioned I did reproduce the behavior. Your new observations is probably a very important clue, I have sent the information on your observations to the developer that is working on on this.
I will post here what the developer found while analyzing, it is his feedback unmodified…
*
We have the same experience here. We cannot reproduce anymore. I’ve tried with the same camera as Bo. I tried to change configuration and test in different ways, but the issue have disappeared.
I’ve checked release of Chrome and found a fix that might explain this:
[crd host] Fix garbled frame stats for extrapolated frames
The frame stats is created by WebrtcVideoStream as
WebrtcVideoStream::FrameStats. However, when WebrtcVideoEncoderWrapper
creates a copy of it for extrapolated frames, it uses the copy ctor of
WebrtcVideoEncoder::FrameStats, which is missing some fields. When
WebrtcVideoStream gets back the frame stats, it down-casts it to
WebrtcVideoStream::FrameStats, which causes out-of-bound reads.
We have also reviewed the issue again on our end and looked into changing browsers.
- The 1fps issue occurred not only in Chrome, but also in Firefox.
- The recordings since September no longer have the 1fps issue, but when playing back VODs from dates when the 1fps problem occurred (August), the issue reproduces in all browsers.
Based on the above, we suspect that it is not caused solely by a Chromium bug.
If the root cause is unknown, we may continue to face the risk of recurrence in the future, so please let us know if you discover anything through your investigation.
Could you please let me know if the root cause of this issue has been identified or if there has been any progress in the investigation?
While there were comments about the possibility of the following Chrome issue, since we have confirmed that this problem also occurs in Firefox, isn’t it likely caused by a different reason? We’d appreciate your comments on that point as well.
We never found the root cause. Our analysis was only theoretically as we could not reproduce when the developer was doing his analysis. We will not pursue this issue as we assume we cannot get closer to finding a root cause as long as we cannot reproduce.
I understand the situation. Please allow me to ask a few questions.
In your recent response, when you say “it could not be reproduced when the developer was doing his analysis,” does this mean that the issue cannot be reproduced in the current environment?
Also, could you confirm whether the issue was reproduced at the time of my post on 22 August 2025 at 06:12?
Lastly, if there is any specific information that should be collected when the issue is reproduced to help with investigation, please let me know.