Is there a way to register a recorder using SDK?
So same process when right click on recording service manager tray icon> register > fill in management server > fill in credentials > OK.
Is there a way to register a recorder using SDK?
So same process when right click on recording service manager tray icon> register > fill in management server > fill in credentials > OK.
There is unfortunately no functionality for this in the MIP SDK currently.
This is on the Milestone SDK team’s wish-list for future enhancement development work, for now it has not been prioritized and it is impossible to say when, or even if, this will be developed.
Ok thanks, is there an other way to automate this?
So in fact, the goal is to start a secondary recorder as it is the primary recorder. This means these steps should be automated:
Unfortunately, in the MIP SDK there is no functionality for this, so it is impossible to do it with MIP SDK.
Whether it is possible to manipulate files and make it work, I do not know.
I doubt this has been tried. It might have been tried and not necessarily by a partner doing development work , there is a little chance somebody tried it and somebody who have tried it will answer if you ask the support community.
Hi Kenny,
You might be able to use MilestonePSTools with the Set-RecorderConfig cmdlet. However I have not tested that cmdlet much since 2019 R2 and there have been some changes made to the way registration is handled. I had some trouble with it recently when I have encryption enabled for Management Server communications.
In 2020 R3 we are updating the ServerConfigurator component which is currently responsible for managing encryption settings and registration. The updated component will introduce some command-line functionality. At that time I’ll update the Set-RecorderConfig cmdlet to use that instead.
Currently the cmdlet is using reflection to import the library responsible for handling registration, and it’s invoking those methods while taking care of updating the RecorderConfig.xml and registering ssl certs if necessary. It’s pretty unstable between versions since it’s not based on MIP SDK so definitely use it at your own risk.
Hi Josh,
Thanks a lot for your answer! This opens another way of doing things in Milestone!
As far as I can see now, I do not need to register the recorder but I will need something else. The goal is to have 2 recorders with identical state (config and recording files).
I managed to write my own service which synchronizes the video files from primary to secondary recorder (for example every hour).
It also checks if the primary recorder is up and running, if not, it will start the secondary with config of primary. This works fine.
However when the primary returns to a normal state, I want to sync the new video files from secondary to primary, so primary has all the video files again.
So in fact the same mechanism that failover server does with the difference that it also holds the video files and does not delete them.
When secondary recorders starts recording, the video files are stored in a folder with the name of the camera (no extents like _LOCAL_TIMESTAMP).
So when primary returns, I should copy this folder to primary mediadatabase and find a way to add this folder as a table to the bank.
The file archives_cache.xml holds all the tables in the bank of the mediadatabase.
I tried adding it manually at the end of the xml but nothing works.
Any idea how I can achieve this? Can the Milestone PS Tools do this for example?
Thanks in advance!
Kenny
That’s a lot to unpack and the short answer is no - pretty much none of this is possible to do with MIP SDK or MilestonePSTools. With the core MilestonePSTools module I try to stick strictly to what is possible with the binaries distributed with the redistributable MIP SDK.
I like your creativity here - it sounds like you’re reproducing at least some of the capabilities of the existing Failover Recording Server features but perhaps you’re building a mechanism to enable the “failover” to access all the prior recordings made so that in the event of a failover, all (or at least most) past recordings made by the original recording server are available for playback during the failover event?
With regard to moving pieces of the media database around, let me first explain the vocabulary I’m using - if not for our benefit, at least for other readers. A bank is a live or archive “root folder”. So if I’m recording to [D:\MediaDatabase,](file:D:/MediaDatabase,) then my bank path is [D:\MediaDatabase\](file:D:/MediaDatabase/).
Inside the bank path you find a config.xml, and depending on the state of the Recording Server and/or the success of the last service shutdown, a cache.xml and archives_cache.xml file. The cache.xml file is only present after a graceful shutdown and is deleted upon the next startup, while the archives_cache.xml file is normally always present.
Also inside the bank path are a number of “tables”. Each of the tables have an ID usually representing a camera/mic/speaker/metadata or edge storage table ID.
As far as I can tell, programatically the names of these folders are basically irrelevant as the cache files describe their contents, and if the cache files are missing, their content is discovered during the indexing process. But typically the folder where live data is written will be named after the ID of the device, and nothing else. When that table is “split” and a new table for live data is created periodically, we rename the folder to “_LOCAL_yyyy-MM-dd_HH-mm-ss” and if/when that table is archived, the “LOCAL” tag is generally replaced with an “ARCHIVE” tag.
Inside each table is a config.xml and some column folders. Those columns each have the same ID in every table that is ever created. For example the “media” column folder name is “7ea9b53b-749e-420b-891b-43b238f6144e” in every table. Each table will have multiple columns containing different types of data for that device for that period of time. One will contain the actual media, one will contain recording sequence information (an index of all of the periods for which there are recordings), motion sequences, motion metadata, recording signatures etc.
When you talk about moving recordings between servers, you’re generally talking about “tables”, and the easiest way to move a table from one server to another (assuming they have the same configuration/cameras/ids) is to copy the tables you’re interested in, and also find the associated node(s) from the cache.xml and/or archives_cache.xml files and add those nodes to the destination server’s cache.xml and/or archives_cache.xml files. Doing this should make it possible to move recordings to another server and make them available without having to force a database re-index.
There might be a supported way of reading the media database files yourself if needed, but it’s beyond my experience. The Media Storage Source Toolkit documentation describes a bit about how to use the C++ Multimedia Tookit SDK components to work with database files.
The issue with moving the “live tables” between servers is that there are probably already some folders with the same name on the server you want to move those folders to. So unless you intend to overwrite them, you would need to possibly rename the folder yourself and manipulate the *cache.xml file(s) to reflect the new name?
It goes without saying that we recommend extreme caution when working with raw media database files/structure and that it’s not generally a supported activity. In your project it may not be relevant to your specific use case, but keep in mind things like database signing and encryption and how that may or may not work well when moving files between physical hosts. It probably works since they will be the “same recorder” but it’s an important area to test.
Hi Josh,
Thanks again for reading, and most of all, understanding my question/problem.
For the 2 questions in your reply, the answer on both is YES.
I tried the following before but again today:
I think the solution is in forcing the indexing process or something else after the copy of the folder is done. Adapting xml does not help it seems to me.
Kind regards,
Kenny
@Josh Hendricks small update on this. My tests lead to the conclusion that only folders that are made by the recorder itself can be transferred and recognized on another recorder.
If I stop the secondary recorder, create a new folder, copy video files from live folder, copy this folder to primary, than this folder is not recognized by the primary. Even if I stop the primary, delete cache.xml and archives_cache.xml.
if I do the same with a folder (with _LOCAL_TIMESTAMP) that is created by recorder, this works. I have to stop primary and delete the xml’s again to be able to playback on the files.
I also had contact with support via the care portal for partners. They sent me to Custom Development. I explained and referred to this post. They suppose that you will be helping me with this and hope we’ll find a solution. Hope this works out…
Kind regards,
Kenny
@Josh Hendricks An extra question regarding your post that registration of a recorder maybe possible using the Set-RecorderConfig cmdlet.
I can see that this also will cause a restart (stop-start) of the recording service.
Is this possible to do only registration and no restart of recording service?
Thanks again!