Recording Server does not pick up changes to hardware definition

We are trying to develop functionality for our video analytics solution to send back metadata into Milestone. For that purpose we are using the MIPDriver framework to create a MediaProviderService that provides a hardware definition with a variable amount of metadata definitions.

For each analytics channel in our application the MIPDriver service advertises a metadata device definition. The amount of device definitions that are advertised on this service can change if analytic channels are added or removed in our software.

However the recording server seems to cache the first retrieval of device information and never seems to reload it.

E.g. the first time we connect to the service it offers 3 metadata devices. Everything works and we can add it as is expected. If we then add another channel and advertise 4 metadata devices I would expect, that with the “Replace Hardware” functionality it would find 4 devices and update the hardware accordingly - but it will use a cached response (there is no load time) and still show only 3. Even if you delete and re-add the hardware it will still show only 3 devices.

We tried to increment/alter the device firmware, MAC address, serialno and name but these changes don’t seem to trigger a reload. I don’t think there other parameters we can tune on our end in the MediaProviderService.

It will only show the correct amount of devices if we change the port of our hardware or if we start/stop the recording server.

I don’t think always restarting the recording server is a acceptable solution in a production environment for our clients. And always changing ports is also less than ideal.

Is there any way to force a refresh of the device?

I am unable to reproduce the behavior you describe in the Milestone test lab.

I setup a test XProtect VMS and using the Management Client (MC) I added the BoundingBoxMetadataProvider sample so that I had a MIP Driver based device with one metadata channel.

I then started the MultiChannelMetadataProvider sample instead, I made a replace hardware, so that the hardware now had 3 metadata channels.

I was immediately able to do a refresh and see the 3 channels in the MC. I did have to make sure that I expanded the filter and made sure “Show disabled devices” was set.

In my test no restart of the recording server was necessary.

My first idea is that you do not see the devices because of the filter / “Show disabled devices” functionality. This might be too optimistic. Let me know. If you still see the issue please elaborate on what you observe, for one thing I wonder if you have feedback from the replace hardware wizard that you can show me.

No, I’m well aware of the “Show disabled devices” checkbox, and that’s not the issue.

I’m on 2023 R2 and retook the steps you did with the metadata samples. I get the same behavior as in my first post sadly.

I did:

  1. Start BoundingBoxMetadataProvider sample on port 52123

  2. Add Hardware → the MC shows a hardware with 1 disabled metadata device

  3. Stop BoundingBoxMetadataProvider, run MultiChannelMetadataProvider on port 52123

  4. Choose Replace Hardware => The device inherit dialog only shows 1 device (3 expected). After confirming the replace it will also only have 1 device still.

Same is true when you delete and re-add.

In addition I found out if you force a connection error, e.g. you turn the service off and then try to add a MIPDriver device with your address/port combination. If you turn it back on and then try to add again it will show the correct devices. So it seems to just “ping” the device and check if it’s there but not fully load the hwdefinition. If it runs into an error it will clear the cache for that specific address/port combination.

Maybe I can create a (somewhat hacky) workaround based on that.

Also there seems to be a time element to the cached hardware definition. After I returned from the weekend and I changed the hw definition updating it worked once.

Here just a screenshot of what it shows after trying to replace the device (from 1 to 3 metadata devices)

It shows only 1 device but 3 would be expected

And this is what it shows after I do my workaround described above (force connection error than try to add again)

It shows 3 devices as is expected

I was able to reproduce as you have explained it. I think that if I do step 3 fast, I can reproduce, if I am not fast I will trigger the connection error that you mention as a possible workaround.

I have the information I need to ask Milestone Development to investigate this. I will update here what we find..

We have now a conclusion from Development doing an investigation..

--

Assumption is that during the test, the user don’t close the whole applications only press corresponding buttons: “Accept Sessions“/”Disconnect Session” of both (BoundingBoxMetadataProvider and MultiChannelMetadataProvider)

Then the issue is in BoundingBoxMetadataProvider sample on port 52123, it dose not free sockets when button “Disconnect Sessions“ is pressed. The BoundingBoxMetadataProvider remain listening on that port and give valid responses.

And during the Replace Hardware responses are from BoundingBoxMetadataProvider and this is why it has only 1 metadata channel.

The following modification in file: XPCO\MIP\Samples\prod\ComponentSamples\BoundingBoxMetadataProvider\MainForm.cs close connection and should work: