VideoOS.Platform.SDK.Environment.AddServer() + Login() URI length problem

MIP
, ,
1

Hi!

After updating Milestone SDK from 2020 R3 to 2021 R2 we started encounter a problem every time Uri field length of VideoOS.Platform.SDK.Environment.AddServer() call is longer than 132 symbols.

It fails with with VideoOS.Platform.CommunicationMIPException “Unable to connect to toolkit!”. We use VideoOS.Platform.SDK.Environment to open files that were previously exported with DBExporter in BLK format.

2

Milestone Development will start an investigation.

3

I’ve been looking into this and I have a couple of questions:

  1. Could you provide an example of a Uri with length above 132 symbols?
  2. What exactly are you including in this count? (is this including the protocol part, for instance?)
  3. What sort of VM are you running this instance on? Our host, for instance, does not support names of lengths above 15…
  4. Would it be possible for you to provide the complete stack trace of the exception you’re seeing?
4

1.Actually, any string longer than 132 symbols.

Few examples:

file://brief-evgeniy/Briefcam/ServerData/VideoData/VideoFiles/FetchedFiles/77/1-17-2022 5_10_00 PM/Sony SNC-VB6xx-VM6xx-EM6xx Series (172.25.25.20) - Camera 1

[\\brief-evgeniy\Briefcam\ServerData\VideoData\WebUpload\yuval\eb7dddeb-8603-4f33-9c85-ac6fc45af246_._03-02-2022](file://brief-evgeniy/Briefcam/ServerData/VideoData/WebUpload/yuval/eb7dddeb-8603-4f33-9c85-ac6fc45af246_._03-02-2022) 08_55_00\eb7dddeb-8603-4f33-9c85-ac6fc45af246

[D:\New](file:D:/New) folder\qwqwef f efwfwfwf\234234 2 242 424 2234\ wefwefwfwfwfwf\2342342342342dd - 23 23 f\123ddd\ggrtgt_34\2343\44.ddd.qqqqq44\Data\8e185259-05e7-4dcd-852b-5c4948c63a55

2.Yes, protocol or disk drive are included.

3.Tested on phisical machine with both local and network paths.

4.Sure.

Exception type: VideoOS.Platform.CommunicationMIPException. Exception message: Unable to connect to toolkit! - .
Stack trace:
   at VideoOS.Platform.SDK.Export.SDKInternalCommandService.ToolkitConnectWithExceptionHandling(IPlaybackSourceToolkit toolkit, ISet`1 properties, ISet`1& availableProperties)
   at VideoOS.Platform.SDK.Export.SDKInternalCommandService.Connect(IPlaybackSourceToolkit toolkit, String additionalProperty)
   at VideoOS.Platform.Data.BitmapVideoSourceImplementer.<>c__DisplayClass3_0.<Init>b__0()
   at VideoOS.Platform.Data.GenericVideoSource`1.InitInternal(Func`1 imageExporterConnect, Action onConnected)
   at BriefCam.MilestoneIntegration.MipsDecoderImpl.Initialize(VideoFileInfo videoFileInfo) in C:\Repos\Integrations\BriefCam.MilestoneIntegration\MipsDecoderImpl.cs:line 223
Inner exception:
Exception type: VideoOS.Toolkit.NotConnectedException. Exception message: Unable to connect to toolkit!.
Stack trace:
   at VideoOS.Toolkit.SourceToolkit.Connect(ISet`1 requestedPropertyNames, ISet`1& availablePropertyNames, TimeSpan timeout)
   at VideoOS.Toolkit.SourceToolkit.Connect(ISet`1 requestedPropertyNames, ISet`1& availablePropertyNames)
   at VideoOS.Platform.SDK.Export.SDKInternalCommandService.ToolkitConnectWithExceptionHandling(IPlaybackSourceToolkit toolkit, ISet`1 properties, ISet`1& availableProperties)
 [In: BriefCam.MilestoneIntegration.MipsDecoderImpl.Initialize]
5

Hi Evgeniy,

We had a similar issue recently regarding export, but as those compoenents are sharing code I tried to use BitmapVideoSource from the hotifxed version with a 240 character long path and it worked fine, so could you please try out with the latest cumulative patch described here:

https://developer.milestonesys.com/s/article/XProtect-2021-R2-cumulative-patch-installers

Direct download link is this: http://download.milestonesys.com/MTSKB/KB000039500/MIP%20SDK/

Unfortunately we have not started pushing hotfixes to NuGet yet (we will do that starting with 2022 R1 release coming next month), so if you are currently using the Nuget packages you will have to replace your references with direct assembly references.

Please let us know whether the hotfix works for you.

Kr,

Peter

6

Hi! Thanks for response!

We use latest SDK build with hotfixes (built on 01/11/2022) and the problem still exists. Is there some newer installer?

7

No that is the latest version. We will try to investigate further.

8

We did further investigation and unfortunately the reason is that the database file structure for the XProtect database means that some files will have a path that is around 126 characters longer than the base path and as a lot of Windows functions only supports paths up to 260 characters long it means that the base path cannot be more than 134 characters long (or maybe 132 as you say if I have overlooked some path that is slightly longer).

This unfortunately means that there is not much we can do about this limit with the current database layout (and we cannot easily change that).

9

Should “long paths enabling” solve this problem?

https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd

Also, were this export database changes made recently? There’s no such problem with 2020R3 SDK.

10

We tested “long paths enabling”, unfortunately it does not make a difference. Retesting, I found that setting the registry and applying the manifest I could both export and open the export while using paths longer than 300 characters.

Without applying the workaround of enabling long paths:

We then tested opening an export. First with MIP SDK 2020R3 PlaybackWpfUser sample then with newest MIP SDK ImageViewerClient sample (same sample but it was renamed) in both cases the path where it failed was the exact same length.

We tested with [E:\Downloads\_exp\longnametest567890123456789012345678901234567890123456789012345678901234567890123456789012\Client](file:E:/Downloads/_exp/longnametest567890123456789012345678901234567890123456789012345678901234567890123456789012/Client) Files\ which means a path that is 122 characters (one extra character put in the path makes it fail).

I am speculating if you have camera names that are longer in one of your tests than in the other test?

11

Hi Bo Ellegard, so as far as I understood we are stuck with this limitation. So I guess we (Milestone and Birefcam) have to come with a cohesion how to proceed with this. Enabling long paths for Win32 does not solved your problem, so maybe we need some compression or UUID resolution in order to make it work. Can we have like a developer session so we can understand between how to nail that problem and see our both sides so we can help each other.

Kind regards,

ilianz

12

I believe Briefcam has a partner representative at Milestone, please bring this up, it might be possible to develop new functionality that will enable exporting to longer paths than what the current functionality supports.

13

Thank you, Bo Ellegard for the assistance you are willing to provide. I will speak with our representative and we may discuss or have a direct meeting with you about that extra fix. You may see my mail in my Milestone account so, you can write me a direct mail to setup a meeting.

14

Hi Ilian,

We are currently looking into this, but I also did a reread of the Microsoft post Evgeniy refers to above and realized that we had overlooked the part about the addition to the assembly manifest. After adding that to the test application everything seems to be working fine, so maybe that could be a work-around at least for now?

Kr,

Peter

15

Hi!

Adding longPathAware element to app.manifest solved the problem. But it works only with executables manifests. Initially I tryed with dlls.

16

Yes, we also realized that, which unfortunately means that we cannot set it for the SDK binaries, and it thus have to be done by the partners utilizing them. We are working on a KB article informing about this.