01304 827609 info@use-ip.co.uk Find us

Firmware M-Series Firmware v5.03 Released

Have you gents noticed that V5.03.010_240606 has been released a few days ago.... DS-7608NI-M2/8P I don't have an M series to test on at the moment but one of my customers has and she also has a DS-KV6113-WPE1(C) connect to it so I'd be interested to know if the issues with getting that working on V5 has been resolved...
Many Thanks Lee...
https://www.hikvision.com/uk/products/IP-Products/Network-Video-Recorders/Ultra-Series/ds-7608ni-m2-8p/?q=ds-7608ni-m2+&pageNum=1&position=2&hiksearch=true&subName=DS-7608NI-M2/8P#download-agreement
err no....which is annoying as I check daily for updates (clearly got too much time on my hands....). Another example of how the Hikvision firmware search is pants. Taking a look now, thanks for the heads up.
 
I've installed it on my DS7616NI-M2/16P. There are no obvious fixes or additions. Perhaps a few elements of the local UI have been altered but I can't be sure as V5 has been somewhat difficult to navigate since day one.
 
FWIW, I suspect this occurred prior to v5.03.010, BUT it caught my attention today. For me,

EVENT MARKERS in PLAYBACK are off by an hour (i.e. event markers are +1 hour from actual)

For example:
  • via WEB UI
  • go to Live View.... all Live View time stamps show the correct DST times
  • go to Playback
  • enter a Search for Perimeter Protection --> Intrusion Detection
    • use today's date and hours 00:00 - 24:00
  • Current real time is 09:18:40
  • Search results:
    • Event Marker shows at 09:46 (aka the little "red" vertical bar)
    • unable to play this event, since it is in the future
  • manually move the playback to 8:46
    • and there is the recording that (I assume) generated the event
This is repeatable. Should I repeat the sequence using a previous day.... the little "red" vertical bars are +1 hour from actual time.

My high level conclusion.... time stamps on recordings look correct, just the Markers are off.

My test environment:
  • DS-7616NI-M2 @ V5.03.010 build 240606
  • DS-2CD2387G2H-LISU/SL @ V5.7.15 build 240201
  • Chrome browser using the Web UI on the NVR
  • devices connected via CISCO POE switch
  • NVR & Camera clocks are sync'd to a CISCO Time Server, all on the same VLAN
  • actual time differences between devices < 1 sec (probably < 500ms but my available tools don't give me that granularity)
  • actual time difference between CISCO Time Server and real time, < 1 sec
  • NVR / Cameras have DST set with DST Bias of 60 minutes
  • SSH command --> getDateInfo <-- run on NVR & Cameras show a respectable / correct time. (e.g. Sun Jun 16 09:18:40 UTC 2024)
 
FWIW, I suspect this also occurred prior to v5.03.010.

A review of my DS-7616NI-M2 LOG records, I find (what looks to me) "literally" 1000's of bogus ANR Record Exception records.

The attached file is a short 15 minute snippet from my LOG. Most timestamps are so far in the past, the creditability of all the ANR records is in question. And for the most part, the records are happening every 5 seconds.

Below are 2 examples. And yes, the time on the NVR & Cameras are all sync'd to my Time Server.

----------------------------
6 2024-6-24 7:15:28 <--- timestamp of LOG record seems reasonable
----------------------------
Major Type: Exception
Minor Type: ANR Record Exception
Local User: N/A
Host IP Address: N/A
Parameter Type: N/A
Camera No.: D1

ANR record type: ANR record for IP camera
Start time: 11-27-2023 17:06:19 <--- Nov 2023 ???
End time: 11-27-2023 17:12:12
Current time: 11-27-2023 17:06:19
Error No.: 0


----------------------------
7 2024-6-24 7:15:33 <--- 5 seconds later
----------------------------
Major Type: Exception
Minor Type: ANR Record Exception
Local User: N/A
Host IP Address: N/A
Parameter Type: N/A
Camera No.: D1

ANR record type: ANR record for IP camera
Start time: 12-03-2023 13:05:29 <--- Dec 2023 ???
End time: 12-03-2023 13:07:16
Current time: 12-03-2023 13:05:29
Error No.: 0
 

Attachments

FWIW, I suspect this also occurred prior to v5.03.010.

A review of my DS-7616NI-M2 LOG records, I find (what looks to me) "literally" 1000's of bogus ANR Record Exception records.

The attached file is a short 15 minute snippet from my LOG. Most timestamps are so far in the past, the creditability of all the ANR records is in question. And for the most part, the records are happening every 5 seconds.

Below are 2 examples. And yes, the time on the NVR & Cameras are all sync'd to my Time Server.

----------------------------
6 2024-6-24 7:15:28 <--- timestamp of LOG record seems reasonable
----------------------------
Major Type: Exception
Minor Type: ANR Record Exception
Local User: N/A
Host IP Address: N/A
Parameter Type: N/A
Camera No.: D1

ANR record type: ANR record for IP camera
Start time: 11-27-2023 17:06:19 <--- Nov 2023 ???
End time: 11-27-2023 17:12:12
Current time: 11-27-2023 17:06:19
Error No.: 0


----------------------------
7 2024-6-24 7:15:33 <--- 5 seconds later
----------------------------
Major Type: Exception
Minor Type: ANR Record Exception
Local User: N/A
Host IP Address: N/A
Parameter Type: N/A
Camera No.: D1

ANR record type: ANR record for IP camera
Start time: 12-03-2023 13:05:29 <--- Dec 2023 ???
End time: 12-03-2023 13:07:16
Current time: 12-03-2023 13:05:29
Error No.: 0
Is there any chance it is genuine and is it only channel D1? I'm wondering if packet loss or a momentary blip in the connection to the camera could trigger that. Do you have ANR enabled on the camera?
 
JB1970, thx for your comments. You've raised some interesting points. FWIW, I've gone down a number of rat holes trying to figure this abnormality out.

I'll comment on your questions first:
  • is there any chance it is genuine
    • A: yes, arguably, in my case, it seems the error messages might be legitimate. I haven't been able to figure out the "why" though.
  • and is it only channel D1?
    • A: it was on Channel D1 and D2. Statistically, many more exception records on D1 than D2. But they were on both D1 & D2 channels.
  • I'm wondering if packet loss or a momentary blip in the connection to the camera could trigger that.
    • A: Possibly. Never say never. I did look into that. My CISCO switch logs did not indicate or otherwise provide any evidence of packet loss/drops. The logs on the cameras did not reveal anything either.
  • Do you have ANR enabled on the camera?
    • A: no and yes. Enabled directly on the G5 cameras, NO. Enabled on the NVR for each camera, YES. And that might be the clue to the root of the problem.
Some additional observations, in no particular order, I made along the way:
  • the timestamps contained "within" the LOG exception records are still bogus / questionable. Dates within 2023 make no sense.
  • activating ANR directly on the cameras does NOT seem possible without providing an FTP Server or Alarm Server. It seems, having an SD card in the camera doesn't count for anything when it comes to ANR. (I might be mis-understanding HIK's ANR design though).
  • I have neither an FTP Sever or Alarm Server in my network, and am not likely to add them. Thus, activating ANR directly on the cameras was not an option for me.
  • on the M-Series NVR, activating ANR is possible / available for each G5 camera. Navigate to:
    • "Storage Management --> Storage Schedule --> Video Recording --> Advanced Configuration".........
      and it can be enabled. One is given an "info" message --> "Configuring the storage medium in camera is needed for the function to take effect". I figured with a working 128GB SD card with tons of free space, I was good to go. I may be mistaken with that thinking.
  • I've confirmed, with the ANR function disabled in the NVR for each camera, the LOG exception records have ceased. These log records did not return when the ANR function in the NVR for each camera was enabled once again.
  • with the NVR powered down for 3 minutes. Then powered on again.... the NVR never caught up on the missing 3 minutes. There's a 3 minute gap in the NVR's playback. (If it counts, the 3 minutes were available for playback, directly on the cameras though).
Bottom line:
  • disable, then enable ANR for each camera in the NVR, followed by a re-boot of the NVR, and I'm back to where I was, but without the ANR Exception records every 5 seconds.
  • does the ANR functionality actually work ? The jury is still out on this one. So far, I'm not convinced.
  • HIK Developers.... you should consider fixing those bogus timestamps within the ANR Exception records. But I'll concede, it's an ultra low priority.
  • I'm really tired of testing this v5.xx from HIK.
I'll leave it there & move along.
 
I only tried ANR once myself solely to see how it worked. It did work for me on that occasion but was a huge resource hog.

I added a new camera to my home network using a WiFi bridge with an SD card inserted and after adding it to the NVR I enabled ANR on the NVR only. While in view of the camera I purposely disconnected the power to the WiFi bridge for a minute to drop the link and then reconnected it. The NVR showed the playback timeline for the missing minute in a different colour and from memory it would playback directly from the SD card while using the NVRs playback interface. The playback was seamless and I could see myself disconnect and reconnect the link in the footage. Over a period of time the SD card footage was copied back to the NVR hard disk. However it just seemed to tie the NVR in knots while the recovery was taking place; the local UI was really laggy and freezing up.

The reason for me trying it was that I was going to hash up a kind of dash cam. The camera would record in vehicle to the SD while I was out and about; once home with my Unifi AP in range, the in car bridge would link the camera back to the NVR and the footage would copy back (I do this sort of crap when I'm bored; my head fills with these ideas!)
 
More possible bug(s)

1 - My home system has been showing Hik-Connect offline when it isn't. Hik-Connect has been working fine, notifications are received, event clips are available, while on my home network and away. However in my Hik-Partner Pro app the site is in the 'exceptions' list and showing offline for days. Rebooting made no difference. So to resolve the incorrect 'offline' message I had to toggle the Hik-Connect enable button. That clears the exception for a very short time, then it returns. While doing that in the 'more settings' pop up Stream Encryption and Adaptive Bitrate Streaming were previously off with Platform Time Sync on. However when the enable is toggled both Stream encryption (not wanted) and Adaptive Bitrate Streaming (mot wanted) get turned on, while Platform Time Sync (needed) gets disabled. Effectively if you toggle the Hik-Connect your system is not time sync'd (as it does not re-enable NTP)

2 - Maintenance Tools > HDD Status Detection. 'It only detects Seagate Skyhawk series HDDs' (both of my HDDs are Skyhawk) Click one of them 'Gathering HDD Information' with a spinning in progress icon appears and remains , then.........nothing - no information when it completes.
 
Dear HIK Developers (if you're still following this thread).... FWIW, the time shown on the Time Sync Diagnosis web page is erroneous.

The "time before sync" is accurate or at least reasonably close to real time.... but the "time after sync" fails to correctly account for the DST Bias of 60 minutes.

Included below is a pic of that web page..... and a copy of the LOG record for that same time sync period.

***************************************************************
* *
* Copyright 2008-2024 Hikvision Digital Technology Co., Ltd. *
* *
***************************************************************

********************* FLASH LOG START *************************

********************* FLASH LOG END *************************

********************** DB LOG START *************************

----------------------------
1 2024-6-26 17:11:40
----------------------------
Major Type: Information
Minor Type: Time Synchronization
Local User: N/A
Host IP Address: N/A
Parameter Type: N/A
Camera No.: N/A

Time Server IP Address: 10.10.10.254
Time sync source: NTP
System current time: 2024-06-26 17:11:40
Time before modification: 2024-06-26 17:11:38

********************** LOG END*************************
Time Configuration - NVR ScreenShot.2.PNG
 
Regarding time sync, I was seeing similar yesterday on another model (DS7608NXI-K2). While the recorder synchronizes to an NTP server, the NVR itself applies the DST bias, as all NTP servers use UTC (which matches GMT for us in the UK outside of summertime). So that time value after sync will be UTC. It seems that the log output is correcting for that while the UI is not which makes it difficult to interpret.

Since I started using Hik Partner Pro I see time sync exceptions daily across sites. It doesn’t seem to matter whether I use NTP or Hik-Connect for the sync,
 
Last edited:
Ahh, that explains the numerous exceptions per day and NVR showing as offline in Hik Partner Pro until I clear them.
I'm not sure why the offline exceptions have started when the system remains online throughout. I'll have to dig a little deeper in the logs, a Hik-Connect offline event usual shows "CIVIL Offline Exception" or similar. Regarding the time sync I noticed that if you change the method NTP to Hik-Connect or manual, the exception remains and the time sync won't show as normal until after reboot (it continues to show multiple sources in use)
 
Has anyone been able to resolve the "Device Type Mismatch" error for door phones / doorbells?
I have to change to Hikvision_RTSP protocol for door phone camera to show up, but the functionality is limited obviously. The playback is also more choppy.

If I try to add the door phone under Access Control Devices, I get the "Network Disconnected" error under Status.
I am on V5.03.010 build 240606 (NVR: DS-7608NI-M2/8P). Using the POE port on the NVR.
 
Last edited:
Has anyone been able to resolve the "Device Type Mismatch" error for door phones / doorbells?
I have to change to Hikvision_RTSP protocol for door phone camera to show up, but the functionality is limited obviously. The playback is also more choppy.

If I try to add the door phone under Access Control Devices, I get the "Network Disconnected" error under Status.
I am on V5.03.010 build 240606 (NVR: DS-7608NI-M2/8P).
It's working fine for me, however there's was a bit of a strange method for adding it; I've just done this now. On the NVR local interface:
  • Goto Device Access > Device > Access Control Device
  • On the top of the screen you should see your device.
  • beneath 'Added/Total' click the '1/1'
  • Mine was showing 'Door1' as added but 'Doorbell' (the name of my 6113) as not added. I clicked the '+' to add it
I can then double click the device and add it with the admin password and port 8000 and it's working as expected.
Using the POE port on the NVR.
This confused me. You've connected the outdoor unit directly to the PoE port of the NVR. How are you getting your calls through to Hik-Connect through the NVR, as the PoE ports re on a different network segment and isolated from the LAN. The usual method is to add the outdoor unit directly to your local network.
 
This confused me. You've connected the outdoor unit directly to the PoE port of the NVR. How are you getting your calls through to Hik-Connect through the NVR, as the PoE ports re on a different network segment and isolated from the LAN. The usual method is to add the outdoor unit directly to your local network.
I have an additional ethernet cable connected to one of the 8 poe ports, which runts to the router. This allows me to tie all the poe devices directly to my main network with manual ip config, without needing to go through the nvr. This essentially allows you to use the poe ports as a stand alone poe switch, without needing an extra device. I have no issue with this setup when it comes to the cameras, only door phone.
 
I have an additional ethernet cable connected to one of the 8 poe ports, which runts to the router. This allows me to tie all the poe devices directly to my main network with manual ip config, without needing to go through the nvr. This essentially allows you to use the poe ports as a stand alone poe switch, without needing an extra device. I have no issue with this setup when it comes to the cameras, only door phone.

Just be aware this config "might" give you issues with "other" DHCP devices in your network.

I'm thinking you might have 2 functioning DHCP Servers in your network.... in which case, it's a race to see which DHCP Server responds first.... and then it's a guess on what IP address you might get. Not a problem for your cameras as you've set them all with static IP addresses.

And if you've already considered & dealt with this.... just ignore my comment. Carry on.
 
For those currently on an older version of firmware (I'm on version V4.61.430 build 231123 here in Australia), is it worth updating to latest firmware available (which is v5.03.000_240814 for me)? My NVR is DS-7616NI-M2 / 16P.

Or is it too buggy / unstable at this stage and is it worth waiting for a future version instead?
 
For those currently on an older version of firmware (I'm on version V4.61.430 build 231123 here in Australia), is it worth updating to latest firmware available (which is v5.03.000_240814 for me)? My NVR is DS-7616NI-M2 / 16P.

Or is it too buggy / unstable at this stage and is it worth waiting for a future version instead?
Usually it's a case of if everything you want works and the update doesn't fix any major security issues, stay on the version you're on :).
I'm running V5.03.010 build 240606 on a DS-7608NI-M2/8P, it fixed some Live View quality issues when viewing through a web browser but as mine is for home use I was fine risking the update.
Only issue I've had since updating: Time stamps on Events an hour behind as described by sportster. Very confusing as the Event even says the correct time but won't be found unless you search the hour before the event.
 
Back
Top