Hi
I am using ImageViewerWpfControl in C#.
I am sending PlaybackData.Goto with the following series of processes.
However, in many cases, the image for the specified time is not displayed.
For a moment, the image at the specified time is displayed, but after that, the image around the time when switching to playback mode is displayed.
How can I switch to playback mode in a series of processes and display the specified time image?
I want you to tell me.
Best regards,
if (EnvironmentManager.Instance.Mode == Mode.ClientLive)
imageViewerControl.StartBrowse();
EnvironmentManager.Instance.Mode = Mode.ClientPlayback;
}
Message message = new Message(MessageId.SmartClient.PlaybackCommand, new PlaybackCommandData() { Command = PlaybackData.Goto, DateTime = dateTime });
EnvironmentManager.Instance.SendMessage(message);
Thank you for answering.
I confirmed the contents.
My problem is with Goto after switching from Mode.ClientLive to Mode.ClientPlayback.
I’m also using UniversalTime and I’m not using Goto during playback.
There is a problem only when running in sequence as presented in the sample in the previous post.
Looking at the behavior, it looks like the Goto is processed before Mode.ClientLive switches to Mode.ClientPlayback and the video stops.
Is there a better way?
Best regards,
I suggest you send a PlayStop before sending a Goto. What do you observe then? (Same issue?)
I wonder if you are using an older version. Please let me know what version is the Smart Client? I would assume you use the newest MIP SDK, if not, what version is the MIP SDK?
Thank you for answering.
Do I need to send Goto commands after switching EnvironmentManager.Instance.Mode from Mode.ClientLive to Mode.ClientPlayback? (Even though it didn’t send anything like the PlaybackData.PlayForward command)
The MIP SDK is installed from NuGet.
The version information is as follows.
MilestoneSystems.VideoOS.Platform.SDK 23.1.2
MilestoneSystems.VideoOS.Platform 23.1.1
Best regards,
I have to say I fail to understand the issue. I thought your first post the Goto was central to what the issue was.
(What is the specified time if not from a Goto command?)
So involving no Goto, can you please explain the issue with other words?
I’m sorry I couldn’t explain it well.
The processing procedure is as follows.
(Execute in one method)
1. EnvironmentManager.Instance.Mode : Mode.ClientLive → Mode.ClientPlayback (Ex: March 4, 2023 at 9:00 AM)
2. Goto Command Send (Ex: Goto Time March 4, 2023 at 8:30 AM)
The expected result is viewing images for 2023 at 8:30 AM.
But the image shows around March 4, 2023 at 9:00 AM.
How do I display the image for March 4, 2023 at 8:30 AM, as I want?
Best regards,
So in this scenario you do send a Goto. Can you test sending a PlayStop before sending the Goto?
Please do another test for me, put a sleep between the mode change and the goto commands. Does it make a difference?
I might have asked the wrong question when asking -What version is the Smart Client?
Is this a standalone MIP SDK application instead of a Smart Client plugin?
Thank you for answering.
1. Sending a PlayStop before sending the Goto
-> The situation remains unchanged.
2. Sleep between the mode change and the goto commands
-> The situation remains unchanged.
The application is not Smart Client plugin.
The application is a standalone MIP SDK application.
Best regards,
I tried to reproduce but was unsuccessful. Could you please try out my way and see if it works for you, I hope we can find a common ground for what is working.
I modified the ImageViewerClient sample, the EnablePlayback() method, and introduced (MainWindow.xaml.cs, line 223, right after “ModeChangeCommand”)
// test
EnvironmentManager.Instance.SendMessage(new VideoOS.Platform.Messaging.Message(
VideoOS.Platform.Messaging.MessageId.SmartClient.PlaybackCommand,
new PlaybackCommandData() { Command = PlaybackData.Goto, DateTime= DateTime.Now.AddMinutes(-15)}),
_playbackFQID);
// test
Please let me know if this works for you or give the same faulty behavior.
Idea: Does it make a difference if you are using “Skip Gaps” or “No Skip” in the sample?
https://github.com/milestonesys/mipsdk-samples-component
Thank you for answering.
I added the test code presented against the sample and tested it.
The result is “Goto Command” failed several times out of 10.
The standalone MIP SDK application I’m creating doesn’t use PlaybackController.
I get the impression that “Goto Command” fails more frequently if you change the sample to not use PlaybackController.
Also, the “Goto command” failed with no difference between “skip gap” and “no skip” behavior.
Best regards,
I had a breakthrough and was suddenly able to reproduce!
My observation is that if you are doing playback close to “now”, switch to live, switch back to playback and does goto, then the chance of reproducing is very high. If you do playback further in the past when you switch back and forth and does the goto, then there is no chance that you will reproduce.
Now that we have a reproduction of the issue Milestone Development will analyze the issue. I will keep you informed about what Milestone Development finds.
Thank you for answering.
I am waiting for further information.
Best regards,
I thought that I had given you feedback that I managed to reproduce and asked Milestone Development to debug. I hope our findings now does not come too late.
We found that what happens is that our handling of change of mode includes a goto call on VideoPlayer with current time of browsecontroller. Next comes the goto initiated by the sample, but after that the VideoPlayer reports back that it has now displayed the image corresponding to the first (internal) goto, which causes ImageViewer to change the time.
As multiple components are syncing with each other we do not see a way to develop a fix, because a fix would probably introduce behavior changes for other uses and jeopardize compatibility with older versions even more. Luckily there is an easy fix for you if you change your code. If you make sure you do the goto before you do the mode change the issue disappears and you get the wanted behavior.
Thank you for answering.
I tried, but the problem didn’t go away.
Can you provide a simple sample code if possible?
Best regards,
Yes..
I use the ImageViewerClient sample..
If you see my post from a month ago starting "I tried to reproduce but was unsuccessful. " This is actually what I used the reproduce when I successfully did reproduce.. So what I need to add is that the order is the key..
In the EnablePlayback() method this reproduces the issue..
EnvironmentManager.Instance.SendMessage(new VideoOS.Platform.Messaging.Message(VideoOS.Platform.Messaging.MessageId.System.ModeChangeCommand, Mode.ClientPlayback), _playbackFQID);
EnvironmentManager.Instance.SendMessage(new VideoOS.Platform.Messaging.Message(VideoOS.Platform.Messaging.MessageId.SmartClient.PlaybackCommand, new PlaybackCommandData() { Command = PlaybackData.Goto, DateTime = DateTime.Now.AddMinutes(-15) }), _playbackFQID);
While this solves the issue (order changed)
EnvironmentManager.Instance.SendMessage(new VideoOS.Platform.Messaging.Message(VideoOS.Platform.Messaging.MessageId.SmartClient.PlaybackCommand, new PlaybackCommandData() { Command = PlaybackData.Goto, DateTime = DateTime.Now.AddMinutes(-15) }), _playbackFQID);
EnvironmentManager.Instance.SendMessage(new VideoOS.Platform.Messaging.Message(VideoOS.Platform.Messaging.MessageId.System.ModeChangeCommand, Mode.ClientPlayback), _playbackFQID);
Note we found this line to be superfluous and will remove it from the sample in the future
_imageViewerControl.StartBrowse();
I am now most eager to hear your feedback, I hope changing the order of these commands is universally beneficial and solves the issue also for you.
Thank you for answering.
I tried your sample code.
I ran into a problem after repeating it a dozen times.
I understand the current situation.
I hope it will improve in the future.
Thank you for your response so far.
Best regards,
There is a minor bug fix and this will be released with 2023R3 version of the MIP SDK. Even with the bug fix applied you will have to make sure to have the order of the commands so that you make the GoTo prior to the ModeChange.
My previous answer was wrong, even with the right order to the commands there is still a small fraction of occurrences where this can go wrong, this will then need the fix that will be released with 2023R3.