IPC-T5442T-ZE IPC-T5442TM-AS IPC-T5842T-ZE SMD 3.0 Smart IR Latest New Firmware From EmpireTech

So I tried the previous stable release of this firmware, 2021-07-29 and noticed that NTP is broken. There were no outbound requests when looking at my firewall logs. I think this is why they enabled NTP logging on 2022-08-18 so they could troubleshoot.

Does anyone have a list of all stable released firmwares for this camera? What is the previous release prior to 2021-07-29?

The only reason I'm upgrading from 2020-12-03 is that all my cameras reboot themselves randomly after 5/6 days.

I'm coming from firmware 2020-12-03 and this new firmware 2022-08-18 spams the log with NTP Set Time entries whereas the old one didn't. Is there any way to disable the logging of NTP updates?
 
Mine works with NTP, it is just very flaky that is takes a while to update first. To be honest, all dahua cameras I have were a bit strange when setting up NTP. I use the ntp.org servers, but I had to set up the right timezone and DST.
 
Are you guys allowing your CAMs to go get time on the Internet? I have all mine point to my NTP Server on my pfSense Router locally.

1683046591787.png1683047153016.png

I opened up port 123 for my CAMs to get to the NTP Server:
1683046976329.png


NetTime

I have used this before pointing to my Router. You just run it as a Service on a Windows O/S machine with Internet access and point all CAMS, PCs, Devices to the machines IP.

It works great as a NTP Server. So for any CAMs that are isolated from the Internet, which all CAMs should be, just drop a PC with NetTime in the same subnet.
 
Are you guys allowing your CAMs to go get time on the Internet? I have all mine point to my NTP Server on my pfSense Router locally.

View attachment 161673View attachment 161675

I opened up port 123 for my CAMs to get to the NTP Server:
View attachment 161674


NetTime

I have used this before pointing to my Router. You just run it as a Service on a Windows O/S machine with Internet access and point all CAMS, PCs, Devices to the machines IP.

It works great as a NTP Server. So for any CAMs that are isolated from the Internet, which all CAMs should be, just drop a PC with NetTime in the same subnet.
Yup. I do something similar as I run a NTP server in a Debian VM I use for various other things. All my 5442 connect to that NTP server and get their time from it with no issue.
 
  • Like
  • Love
Reactions: RyanB and David L
Is getting the time from the internet considered as not secure?
I have only a router (which functions as a vpn server). Have no other server or computer in my system, so I can't set my own ntp server.
 
  • Like
Reactions: David L
So I tried the previous stable release of this firmware, 2021-07-29 and noticed that NTP is broken. There were no outbound requests when looking at my firewall logs. I think this is why they enabled NTP logging on 2022-08-18 so they could troubleshoot.

Does anyone have a list of all stable released firmwares for this camera? What is the previous release prior to 2021-07-29?

The only reason I'm upgrading from 2020-12-03 is that all my cameras reboot themselves randomly after 5/6 days.

Are you sure an auto reboot isn't set up?

If you have an SD card in it, is it full and wonking out every 5/6 days?

Does the firmware update notes indicate it fixes random reboots? Make sure you know what the firmware update fixes/adds/deletes/breaks before deciding on updating.
 
  • Like
Reactions: David L
Is getting the time from the internet considered as not secure?
I have only a router (which functions as a vpn server). Have no other server or computer in my system, so I can't set my own ntp server.
It just means your cams have internet access which in of itself represents a security issue. You could always buy a cheap RPi and run the NTP server from that.
 
  • Like
Reactions: Ollie and David L
It just means your cams have internet access which in of itself represents a security issue. You could always buy a cheap RPi and run the NTP server from that.
 
  • Like
Reactions: biggen
I've done some further digging and found some unexpected behaviour.

On my IPC-T5442T-ZE (FW 2021-07-29), sync'n via NTP works, but only if not using the default entry of clock.isc.org.
If it's set to clock.isc.org, there isn't any DNS/NTP/outbound traffic related to it in my FW logs.
If I set it to any other time server (e.g. time.windows.com) it works.

My guess is on this firmware, clock.isc.org may be hardcoded to a loopback IP hence no outbound traffic.

Mine works with NTP, it is just very flaky that is takes a while to update first. To be honest, all dahua cameras I have were a bit strange when setting up NTP. I use the ntp.org servers, but I had to set up the right timezone and DST.
 
I've done some further digging and found some unexpected behaviour....

Looks like it's been shut down:
Welcome to clock.isc.org.

ISC has shut down its NTP service due to an office move. The Network Time Foundation has taken over providing timeservice to existing users.

We are aware that this server is not currently acting as a Stratum 1 server.
 
I've done some further digging and found some unexpected behaviour.

On my IPC-T5442T-ZE (FW 2021-07-29), sync'n via NTP works, but only if not using the default entry of clock.isc.org.
If it's set to clock.isc.org, there isn't any DNS/NTP/outbound traffic related to it in my FW logs.
If I set it to any other time server (e.g. time.windows.com) it works.

My guess is on this firmware, clock.isc.org may be hardcoded to a loopback IP hence no outbound traffic.
Yup don't use that server. Pointing to generic pool.ntp.org should work fine. If you want a server closer to your geographical regions read here: pool.ntp.org: the internet cluster of ntp servers
 
  • Like
Reactions: danieln and David L
So far, I have used my T5442 to save the video events on the inserted microSD card. I would like to use NFS or FTP to save the videos on another device to view and back up the material more easily. However, using either NFS or FTP results in corrupted DAV files. There are block artifacts present in the video frames during the first seconds of the captured video material, and the video is frozen. After a few seconds, the video becomes normal again. This happens both with H265 and H264 codecs, but not always. The bitrate is 4096 kbit/s. I would say every 15th triggered event is corrupted.

On the FTP/NFS server, I use SSD, so the problem is not because of a slow hard disk. What is more, the traffic on the local network is minimal, and I doubt the traffic from the camera to the server suffers from many-second delays or buffer bloat. Do you have ideas where the problem might be, or have you had similar issues?

The firmware version is V2.840.15OG00D.0.R, Build Date: 2022-08-18.
 

Attachments

  • corrupted video frame.png
    corrupted video frame.png
    276.3 KB · Views: 13
So far, I have used my T5442 to save the video events on the inserted microSD card. I would like to use NFS or FTP to save the videos on another device to view and back up the material more easily. However, using either NFS or FTP results in corrupted DAV files. There are block artifacts present in the video frames during the first seconds of the captured video material, and the video is frozen. After a few seconds, the video becomes normal again. This happens both with H265 and H264 codecs, but not always. The bitrate is 4096 kbit/s. I would say every 15th triggered event is corrupted.

On the FTP/NFS server, I use SSD, so the problem is not because of a slow hard disk. What is more, the traffic on the local network is minimal, and I doubt the traffic from the camera to the server suffers from many-second delays or buffer bloat. Do you have ideas where the problem might be, or have you had similar issues?

The firmware version is V2.840.15OG00D.0.R, Build Date: 2022-08-18.
Which SD card are you using? I'm using a Samsung Pro Endurance and it works flawlessly. Same firmware.
 
As an Amazon Associate IPCamTalk earns from qualifying purchases.
  • Like
Reactions: looney2ns
Is the camerdata running through a router to get to the nas?
It shouldn't, the NAS and the camera should be plugged essentially into the same switch.
Check cables.
Why we harp about NEVER using CCA ethernet cable. | IP Cam Talk
Q&A: Are YOU terminating your Ethernet cable all wrong? You probably are!
Calculating Ethernet Cable Overall Channel Length for Success

Actually, I do not have a dedicated switch. The data goes through my home router, but as I said, there is virtually no other traffic than the camera data. But maybe a direct connection would make sense. I was thinking of a dedicated switch at some point to save camera data 24/7 to an HDD but gave up on the idea for now.

Download a suspect dav from the camera to a pc via the web interface. Play using VLC. No problem with that?
Yes, the DAV files saved on the microSD work and play fine in VLC. No artifacts at all, and the video plays smoothly.
 
Actually, I do not have a dedicated switch. The data goes through my home router, but as I said, there is virtually no other traffic than the camera data. But maybe a direct connection would make sense. I was thinking of a dedicated switch at some point to save camera data 24/7 to an HDD but gave up on the idea for now.


Yes, the DAV files saved on the microSD work and play fine in VLC. No artifacts at all, and the video plays smoothly.

Going thru the router is the problem.

Cameras connected to Wifi routers (even hard-wired) are problematic for surveillance cameras because they are always streaming and passing data. And the data demands go up with motion and then you lose signal. A lost packet and it has to resend. It can bring the whole network down if trying to send cameras through a wifi router. At the very least it can slow down your entire system.

Unlike Netflix and other streaming services that buffer a movie, these cameras do not buffer up part of the video, so drop outs are frequent, especially once you start adding distance. You would be amazed how much streaming services buffer - don't believe me, start watching something and unplug your router and watch how much longer you can watch NetFlix before it freezes - mine goes 45 seconds. Now do the same with a camera connected to a router and it is fairly instantaneous (within the latency of the stream itself)...

The same issue applies even with the hard-wired cameras trying to send all this non-buffer video stream through a router. Most consumer grade wifi routers are not designed to pass the constant video stream data of cameras, and since they do not buffer, you get these issues. The consumer routers are just not designed for this kind of traffic, even a GB speed router.