Camera ID Recording Directory Adjustments / Camera ID API Adjustments
While trying to find a way to easily identify a specific camera's recording directory (when using the UUID instead of the MAC), I found within the API that there are two forms of ID that can be given to the camera -
id
physicalId
"id" would refer to the camera ID found under Camera Settings> General.
"physicalId" will often provide a server-created UUID, which is used as the folder directory for the camera's recordings.
Since there is already an existing
mac
having "physicalId" seems redundant. The camera is already identifiable by its MAC address, and the "id" is already a server-created ID, it seems to me that the "physicalId" can be removed entirely.
Instead, the directories could forgo the use of the MAC altogether and only use a server-generated ID - the camera's "id" instead of "physicalId"
This would be beneficial for a few reasons -
1) Identifying the camera's recording directory would be much simpler. If someone needs to check the directories for any reason, its much simpler to say "look at the camera ID in the settings, then check the directory" than it is to express the use of API (for the majority of our customers).
2) It may simplify the use of API, since there is less of a chance of someone using the wrong ID for a function. You can't get it wrong if the camera only has one ID you need to worry about.
3) It's more uniform. Instead of a directory with a mix-match of MACs and UUIDs, they could all just be UUIDs.
I also understand that there may be some other uses for the "physicalId" that I'm just not currently aware of, but currently it appears to me that instances where the MAC is needed, you could just pull it using "mac". Instances where a UUID is needed, you could just use the "id", and "physicalId" could be removed.
I had made mention of this on one of my tickets with your support team and it was asked if it was common for our customers to need to access the directories, since DW Spectrum (Witness) already provides the recordings within the client. Likely to determine if what I was suggesting was worth the developer time to implement.
This is something where my #1 example above is common for our support team (and where customers get lost trying to figure out what directory has which recordings). To provide some examples:
- Reversion from 5.x to 4.2: Some customers find that 5.x to be unstable for their environments. While we obviously would want to identify and correct the issue, they find it simpler to revert to 4.2, especially if its a critical system that can't be afforded the time to troubleshoot. Once reverted, they can't access the recordings using the client, since 4.2 does not register the 5.x server GUID directory. They may want to back up specific camera data before clearing out the GUID folder so 4.2 can use the entire volume.
- Index Database Issues: There have been times where the raw data exists but the index database does not register the data and doesn't show it on the client (even after a re-index or clearing the index to make a new one). We may need to access the direct .MKV file since Spectrum is unable to see it.
- Verification of recorded data: There may be scenarios where there is actually nothing wrong with the server but the customer wants to be certain that there is no data (for example if the data was overwritten or if the data just wasn't recorded do to a configuration like motion area). You'd be surprised how many times I actually get a call where someone needed data that was just overwritten due to the retention period. But we'll need to show them that it actually doesn't exist anymore because of the overwriting process.
-
https://meta.nxvms.com/doc/developers/api-tool/rest-v2-devices-id-get?type=1&system=4
Looking at this physical ID is needed because some devices will not generate with MAC :)
I feel like physical ID for identifying footage is good, like if you replace a camera under the came record you can maybe track which footage was for each one?
0 -
- Authorized Reseller
I'm aware that not all of the devices will provide a MAC depending on how Onvif is communicating, which is why I understand the need for the UUID. But that's where the question comes in of "why use the UUID at all instead of just using the "Camera ID" that is found under "camera settings" when writing the directory to store the footage?" Since both the camera ID and UUID are server created, it seems logical to me to change the parameters to only use the camera ID instead of the MAC or UUID when writing to the current 5.x directory path. This way, its very easy to know what directory to use without the use of API, and the directory is much more visually organized. This eliminates the need for the MAC or UUID information for the directory and makes it much easier to work with in the future.
0
Please sign in to leave a comment.
Comments
2 comments