Hi, I discover resource release trouble in ImageViewerControl component. I analyzed your component samples VideoViewer and PlaybackUser with dotMemory and found that ImageViewerControl doesn’t release resources after dispose method. To recreate this you can just open few cameras in your samples. You can found some details from the dotMemory report below. Hope you can fix it asap, we have problems in our applications because of this.
Milestone Development have analyzed and found the cause of this issue. A hotfix will be developed. I will update you when I have further news.
Milestone Development have developed a new MIP SDK to hotfix this. Please download and install this MIP SDK.
We will appreciate if you give us feedback when you have tested with the newer SDK whether it works as expected.
Thank you for your answer. Our application is x86 so we need 32-bit redistributable package to test it. Could you please provide it?
Milestone Development will need to do another build. I will update you when I have further news.
Milestone Development now made a new redsitributable from which you get the 32 bit files..
Your feedback will be appreciated.
Thank you for this build! I checked it out with VideoViewer and our software and it works much better. But unfortunately, I found trouble with unmanaged memory. Same case as before just open cameras one by one in VideoViewer and unmanaged memory utilization increases with each camera as you can see on screenshots below. Probably there is some trouble in native code. This is a big problem for us as our users often switch between views of 16 cameras.
Screenshots description:
1. The first camera in view.
2. After 40 cameras.
3. No camera in view.
4. dotMemory report, possibly it can be useful for you.
Milestone Development will be working on this. Allow me to suggest as a quick fix now and here that you try to reuse the ImageViewerControl for another camera instead of creating an new ImageViewerControl every time. I hope it will be a feasible solution for you.
We have been investigating this and tried to reproduce the leak in unmanaged memory by making the VideoViewer sample automatically do a change of camera every second in the same way as is done by clicking the Select Camera button.
Unfortunately we have not found anything of significance even after 2000 iterations.
We have found a very minor leak in the Intel code we are using, but only in the matter of bytes (80) for each change, so nothing close to what you are reporting.
We have tried running the test with both 64- and 32-bit versions of our libraries and with very similar results.
So unfortunately we will not be able to do more about this unless you can provide more information on where the leak happens.
In any case it is also recommended to reuse the ImageViewerControls as Bo describes above instead of creating new ones every time. I hope this will be an acceptable solution for you.
I followed your advice and made a version of VideoViewer that reuse ImageViewerControl, but unfortunately even this did not help.
The memory still leaking. I tested both version of VideoViewer on 3 different machines - Windows 7, Windows 8.1 Virtual Machine and Windows 10. In all cases, both versions of VideoViewer behave the same. During my test, I maximize window of VideoViewer and select cameras one by one with few seconds period to make sure that video stream is established and after about 10 cameras I can see that memory usage increased by 50-100 MB and size of leaked memory depends on quality of stream so maximized window helps to notice it faster. I attached dxdiag reports from all machines and also both samples that I used to test you just need to add MIP libraries from you last build - HotfixBuild_MIPSDK_2017R3_Redist_Installer_x86.msi. Also, what is an appropriate way to reuse ImageViewerControl? Is what I used in reuse sample right or you can recommend something better? I’ll be glad to see a sample from you.
Some details about server and cameras/codecs:
Xprotect Corporate 2014 (7.0d build 871)
z(Legacy) AXIS P12xx/P13xx - H264
AXIS 1 channel PTZ device - MJPEG
AXIS 8 channel device - H264
Pelco NET300/350 - MJPEG
AXIS 1 channel device - H264
Videotec IP PTZ - MJPEG
Hi Ilya,
I tried to reproduce using your new sample, but still with no luck. I also tried with hardware accelleration disabled as it seemed from the dxdiag files that your hardware (i5) does not support this, and with maximized window, but still without reproducing. Even after 100 iterations.
Do you see a continuous climb in memory usage if you do 10 more iterations? And what are the resolution of the cameras you are using?
Best regards,
Peter
Hi Peter,
I’m so surprised that leak is not reproducing in your environment.
About your questions. Yes, the memory keeping up after 10 iterations and cameras has different resolutions from 352x288 to 2592x1944.
I begin to suspect that maybe problem in our network architecture because it is kinda complicated although we did not have this problem on previous SDKs.
I will try to deploy a test milestone server in the same subnetwork with a client and check it that way. I will keep you informed.
Hi again,
The memory consumption will become fairly high if the display size of the image viewer is large. And from our tests it will grow for the first approximately 10 iterations, but then normally drops to pretty much the same level as after the first instantiation and will then stay there as you can see from this image:
If you in your test could also try to isolate a specific camera, so that you can let us know the camera model, codec and resolution, we could also try to reproduce using the same.
Br,
Peter
Peter,
I deployed Xprotect Professional 2017 R2 (11.2a) on Windows Server 2012r2 English version on a virtual machine and connect one axis camera, driver - AXIS M3004.
I ran both samples on the server itself and saw the same problem as before. So it is not a network and not a Windows language. But then I tested samples on another real machine with Windows 10 with both production and test servers and it behaves exactly as you describe memory rise for about 10 iterations and then stabilized. Looks like the problem in machine configuration but I don’t understand what exactly. I think you can reproduce this issue on Hyper-V virtual machine. Or if it convenient I’ll be glad to provide access to our environment thru TeamViewer. I attached dxdiag reports from both server and Win10 machine.
Hi Ilya,
The guy knowing most about these things are unfortunately ill at the moment. I will follow up and get back to you as soon as he is back at work.
Best regards,
Peter
Hi Ilya,
Sorry for the delay. The guy I was referring to is back, but unfortunately I then became ill myself.
He does not know of any known issues with the setup you describe, and his only suggestion is to check that you have all the newest graphics card drivers on the machine.
I also tried running the repro sample on a Win 2012R2 on a virtual machine, but even after 1000 iterations I still does not see any significant raise in memory usage.
So for now our only suggestion is to check whether you have the newest drivers installed. 
Best regards,
Peter
Hi Peter,
I think I found a source of the issue. The memory leak happens only when I connected to machines with RDP, except windows 10, with windows 10 it always works well. We usually use RDP only for maintenance and debug but it still will be great if you can fix it.
Hi Ilya,
We ran through our backlog and looked for old bugs regarding memory leak and RDP, and we actually found one (not on the SDK, but in the Smart Client using the same components). In that case it turned out to be due to a bug in the Microsoft .NET and it was fixed by Microsoft in .NET 4.7. This version is on all updated Windows 10 machines and we have also installed it on our Win 2012R2 test VMs, so it could explain why I cannot reproduce. Could you please check which version of .NET you have on the Win2012R2 and if it is older than 4.7 then try to upgrade?
Best regards,
Peter
Hi Peter,
I don’t have access to Win 2012R2 right now but I checked frameworks on two other machines VM with Win 8.1 and a real one with Win 7. And you right both of them has .Net older than 4.7. After update Win 8.1 works great! Win 7 works better but still has some leak but I think that some windows updates will fix it. Thank you very much for your help I highly appreciate it!