Configuration Changed Indication

We have setup this in init and registered for ConfigurationChangedIndication event.

EnvironmentManager.Instance.EnableConfigurationChangedService = true;

ConfigchangeRef = EnvironmentManager.Instance.RegisterReceiver(ConfigChangeHandler, new MessageIdFilter(MessageId.Server.ConfigurationChangedIndication));

private object ConfigChangeHandler(VideoOS.Platform.Messaging.Message message, FQID destination, FQID source)

{

  if (message.RelatedFQID.Kind == myplugin.mypluginDefinition.mypluginKind)

  {

    //This is called when ever plugin configuration are chnaged in management

  }

  return null;

}

Even though we have not changed the plugin configuration, in smart client we are continuously getting ConfigurationChangedIndication for the plugin.

The same was working previously till 2018 R2 and earlier , not its broken in 2018 R3

Its seriously affecting our sales and demos with R3.

Can you please take a look

We are using

Milestone Corporate 2018 R3

MIPS SDK 2018 R3.

@Bo Ellegård Andersen (Milestone Systems)​ @Anders B. Christensen

​ can you please have a look ​

We will do some investigation here at Milestone..

We tested with the code snippet you show here in a Smart Client plugin. We see one message after the startup of the Smart Client, and then nothing more.

Have you tried this, test without the parts of your plugin that could do changes?

You see this message continuously, how frequent?

Does you plugin reside in Management Client and/or Event Server also?

We might need more information, ideally we woud like to see a minimal implementation plugin project that could reproduce the issue. If this is possible for you to make we would debug it here at Milestone.

“We see one message after the startup of the Smart Client” - we had not seen this in before/earlier releases unless we save plugin from management client, why in 2018 R3 we get this on startup?

Even though no changes has been made during or after opening smartclient in management client we get this event , our plugin is designed to instruct user for relogin when we get this ConfigurationChangedIndication event.

we will check the frequency,

I think the message at startup has always been there..

Quote from VideoOS.Platform.Background.BackgroundPlugin Class Reference

--

Don’t read the plugin configuration in the Init() method, as it is not guaranteed to be ready at this time. Instead listen for the message with MessageId == Server.ConfigurationChangedIndication and load the configuration once this is received. It will be sent once configuration is ready and also no later than 60 seconds after configuration has been changed by the administrator.

--

We had not changed any code from last two MIPS SDK releases, but now its broken in 2018 R3.

Previously we were not getting on startup and was getting only upon plugin change/saved from management client

We have same plugin running in 2018 R2 system which is not firing ConfigurationChangedIndication , but on new system with 2018 R3 its firing ConfigurationChangedIndication without any change, please help

The quote I mention might refer to Event Server background plugin development, and then it might not be relevant for a Smart Client background plugin.

My observation is that the behavior is the same if you use an older XProtect VMS, but the behavior has changed when you compare Smart Client 2018R3 and Smart Client 2018R2.

Instead of asking the user to login again you could use VideoOS.Platform.Configuration.RefreshConfiguration and update your plugin.

I have reported this behavior change to Milestone Development and will update here when I have feedback.

Its firing once after 1 min as soon as smartclient is started and then its fires as usual whenever we save plugin in management client.

any workaround as of now?

To workaround would be..

Instead of asking the user to login again you could use VideoOS.Platform.Configuration.RefreshConfiguration and update your plugin.

Development is working on a hotfix.

If you have something critical, the easiest might be to use Smart Client 2018R2 until a hotfix is ready for 2018R3. (99 out of 100 times the advise is tho use the newest Smart Client so this is an unusual advise.)

Any sample to refer for VideoOS.Platform.Configuration.RefreshConfiguration

I did an experiment, I modified the SensorMonitor sample.

  1. Modified plugin.def so that the plugin loads in Smart Client
  2. Modified the background plugin so that it loads in Smart Client
  3. Modified the event ControllerConfigChangedHandler event handler
// 2:
public override List<VideoOS.Platform.EnvironmentType> TargetEnvironments
{
	get
	{
		return new List<EnvironmentType>(new[] { EnvironmentType.Service, EnvironmentType.SmartClient });
	}
}
 
// 3:
if (EnvironmentManager.Instance.EnvironmentType == EnvironmentType.SmartClient)
{
    List<Item> cnf;
    int count;
//Configuration.Instance.RefreshConfiguration(SensorMonitor.SensorMonitorDefinition.SensorMonitorCtrlKind);
    cnf= Configuration.Instance.GetItemConfigurations(SensorMonitorDefinition.SensorMonitorPluginId, null, SensorMonitorDefinition.SensorMonitorCtrlKind);
    count = cnf.Count;
    EnvironmentManager.Instance.Log(false, "SensorMonitorBackgroundplugin", $"Controller configuration changed, It had {count} controllers");
}

What I learned from the experiment is that the RefreshConfiguration is not necessary! You can just use the GetItemConfiguration.

But you would probably need the GetItemConfiguration to transfer to whatever variables you are using in your plugin..

Sorry, there is no sample, I hope this small snippet of code and my comments will be sufficient.

If you want to solve the issue with your present plugin, not doing any development work on it, but use it as it is, Milestone have now developed a hotfix:

https://developer.milestonesys.com/s/article/Configuration-Changed-Indication-event-can-cause-plugins-to-malfunction-hotfix

Hi Bo,

The hotfix is working fine with unmodified previous plugin .

But we also did the plugin change as suggested by you( Configuration.Instance.RefreshConfiguration) and this does not work with hotfix, but works fine without hotfix.

Does your workaround rely on ConfigurationChangedIndication happening at start-up? If so the workaround will not work on the older (or on future 2019R1) Smart Clients either.

I would like to understand your workaround because it is a bad thing if you need different versions of your plugin for different versions of the Smart Client. Can you please describe or document how your workaround is implemented? You can perhaps use source code snippets to explain.

Without any changes in existing plugin with hotfix the problem is solved.

We have development next version of plugin with changes as suggested by you

“Instead of asking the user to login again you could use VideoOS.Platform.Configuration.RefreshConfiguration and update your plugin” , this works without the hotfix since we reload automatically.

Will the future MIPS release will work as expected with “VideoOS.Platform.Configuration.RefreshConfiguration and update your plugin” right?

The future releases will work like the 2018R2 and earlier versions did.

We reported the behavior you observed in 2018R3 as a unwanted change, and this is what was fixed.

When I test SensorMonitor sample as mentioned above, I see the same behavior in the 2018R2 and in the 2018R3 onto which I have applied the hotfix VideoOS.Platform.dll.

I must therefore suspect that if your newer plugin implementation does not work with the hotfix, it might never work.

Troubleshooting this you might tell me more about your new plugin implementation and I can try to see if I can figure out if anything is missing..

With hotfix VideoOS.Platform.dll replaced in smartclient,

new changes in plugin include the line suggested by you “VideoOS.Platform.Configuration.RefreshConfiguration and update your plugin” , now we are not getting the latest modified configuration until relogin

For me the hotfix works.

For troubleshooting, I will try to outline how I think your plugin works, so please correct me if wrong, and clarify if unclear.

When the ConfigurationChangedIndication happens, in the event handler, you will do a GetItemConfigurations and use the data to refresh all your local variables etc. in your plugin.