Server time through API

Answered

Comments

7 comments

  • Avatar
    Andrey Terentyev

    Hello,

    However, this time does not necessarily correspond to the output from `getMediaServersEx` for the value in "addParams", `timezoneUtcOffset`

    That seems to be a bug.

    Finally, when we log in to the Nx online dashboard in the "information" tab, we see time information different than that provided through the above mentioned `getMediaServersEx` query.

    Could you, please, elaborate on it? Share a screenshot and description of what is expected, what is actual value.

    (there are even more confusing things like individual cameras showing a different time altogether from the media server as the timestamp on the image, but then some cameras on the same server showing the same time as the media server...).

    Could you please give a detailed example with a screenshot and description of expected and actual results?

    I want to report to the user that the timestamp of each individual camera is correct. 

    I'm afraid I don't understand your objective. A timestamp is usually used to indicate a moment of time, to which a certain entity (a frame, request etc). A timestamp is not usually implemented as a characteristic of a camera.

    JIRA-VMS-37317

    0
    Comment actions Permalink
  • Avatar
    Daniel Reichman, Ph.D.

    Example of `information` tab being different than the value reported by getMediaServersEx. Here it says UTC-5 which is correct; the query says  {'name': 'timezoneUtcOffset', 'value': '-14400000'} which is UTC-4 I wonder if there is a DST thing going on, but I do not see any info about daylight savings in the output of this query beyond UTC offset.

     

    Example of a camera's timestamp being completely wrong even though server time as reported by the query is correct.

     

    Finally, here are examples of the UTC offsets from `getMediaQueryEx` from two different and unrelated installations which shows seemingly random utcOffsets for servers that I know are all in the same timezone (server name, then the utcOffset as reported by the query; blank means it was reported as blank from the query)

    Example #1
    [('server1', '-18000000'),
     ('server2', '-14400000'),
     ('server3', '-14400000'),
     ('server4', '')]

    Example #2 
    [('server 1', '-14400000'),
     ('server 2', '-14400000'),
     ('server 3', '-14400000'),
     ('server 4', '-14400000'),
     ('server 5', '-18000000'),
     ('server 6', '-14400000'),
     ('server 7', '-14400000'),
     ('server 8', '-14400000'),
     ('server 9', '-14400000'),
     ('server 10', '-18000000'),
     ('server 11', '-25200000'),
     ('server 12', '-14400000')]

    0
    Comment actions Permalink
  • Avatar
    Daniel Reichman, Ph.D.

    I understand your point about the cameras not having an individual timestamp and I agree this is not necessarily important. However, the servers have a timestamp and I want to be sure they are correct. The reason I mentioned the camera timestamp is because of the screenshot I shared here, seeing that the camera can watermark a completely different time from the media server which itself is different from the VMS just added to my confusion in general.

    Therefore, any disambiguation is appreciated!

    Thanks

    0
    Comment actions Permalink
  • Avatar
    Andrey Terentyev

    Daniel,

    Regarding time on a camera.

    Make sure the "Trust camera timestamp" option is unchecked on the "Camera Settings-> Expert" tab

    1
    Comment actions Permalink
  • Avatar
    Daniel Reichman, Ph.D.

    Hi, thank you for your reply regarding the camera timestamps but I am still waiting on a response regarding the server timestamps.

    We just ran into an issue where the "getMediaServersEx", property "timezoneUtcOffset" query returns an offset of -14400000 while the spectrum interface returns UTC-5

    Version 4.2.0.32842
    Platform windows_x64

     

    0
    Comment actions Permalink
  • Avatar
    Daniel Reichman, Ph.D.

    Hi, any update on this please?

    0
    Comment actions Permalink
  • Avatar
    Andrey Terentyev

    Hello Daniel,

    The issue has been fixed in the latest patch for v5.0. There are no plans to fix it in v4.2. We encourage you to upgrade to v5.0.

    0
    Comment actions Permalink

Please sign in to leave a comment.