SD49225T-HN frequent restarts

[Q™]

clear your browser cache maybe

Gracias amigo!

 

[Q™]

I just applied this new 11/24/2018 firmware to my SD49225T-HN. I'll factory default the camera now and we'll see what happens. Here's what I'm left with...

Version
Device Type SD49225T-HN
System Version 2.623.0000000.7.R.R4.2510.9A.NR, Build Date: 2018-11-24
WEB Version 3.2.1.662493
ONVIF Version 16.12(V2.4.3.580229)
PTZ Version 3.02.93.RHNZ_170518_22722
S/N xxxxxxxxxxxxxxxxx
Safe Baseline Version V1.3
Copyright 2018, all rights reserved.​

 

[SkyLake]

" data-source="post: 318261" class="bbCodeBlock bbCodeBlock--expandable bbCodeBlock--quote js-expandWatch">

Well @SkyLake? Has it fixed the issue?

Actually, i don't know, as i am not experiencing the restart issue. My cam works just fine.

I mostly flash new firmware on the camera's for a testing perspective. It's the researcher in me lol.

But i hope that the issue is fixed for other users who have issues with the cam

 

[MC1987]

Interesting... whats the theory, that the firmware corrupted on factory flash, so doing it this way helps ensure a "clean" updated firmware?

I am no coder but it seems to be corruption of some sort.

Hopefully Q can try this first as I'm still too lazy (and too cold) to take mine down for bench testing or this flashing
I also don't relish the idea of having to open up the camera to access there serial device

 

[MC1987]

I have many Dahua cameras and never experienced this before. Sounds like bullshit to me.

Not bullshit mate, I have probably dealt with more Dahua cameras than you ever will. I wont bother helping you further. Good luck figuring out how to solve your issue even though I have given you what you need.

 

[alastairstevenson]

Not bullshit mate,

Update over rs232, run a tftp server with all of the composite files for the camera in a correctly name folder,
Start up camera,
Stop boot up in terminal software using *****
type "lip 192.168.1.108" press enter
"sip 192.168.1.200" press enter (this will be your computers ip)
"saveenv" press enter
" run up" press enter
You should get a lot of ######## on screen once its upgrading.

I have solved this issue many times using this method.

To be honest - this makes no sense to me.
You're quoting a need to open up a camera and do a a firmware update with an unspecified version to deal with an instability issue.
And the 'run up' is for the image, not the component files.
I get that there may be some fixes in some firmware updates, but you've not given any usable detail.

What's different in the end result to doing the normal web GUI or tftp update and avoiding the risk and consequences of opening the device up?

I have given you what you need.

You haven't really - there is nothing for anyone to use there.

 

[SkyLake]

Not bullshit mate, I have probably dealt with more Dahua cameras than you ever will. I wont bother helping you further. Good luck figuring out how to solve your issue even though I have given you what you need.

Bruce almighty??

 

[Q™]

I just applied this new 11/24/2018 firmware to my SD49225T-HN

No joy...my SD49225T-HN is still rebooting. I've now tried 4 different firmwares, all to no avail. This issue must reside around either (1) a bad crimp or (2) the PoE+ Switch powering the unit. I tried 2 different POE switches, but they were both BV-Tech switches. I'm going to a try a TrendNet PoE+ switch I've got laying around and see what happens. Still trying to resolve this issue.

 

[JayS_IPCams]

No joy...my SD49225T-HN is still rebooting. I've now tried 4 different firmwares, all to no avail. This issue must reside around either (1) a bad crimp or (2) the PoE+ Switch powering the unit. I tried 2 different POE switches, but they were both BV-Tech switches. I'm going to a try a TrendNet PoE+ switch I've got laying around and see what happens. Still trying to resolve this issue. View attachment 36289

I have tried TrendNet, and now Zyxel switch. Both didn't resolve my issue.

I still have to rule out a "bad crimp" (which I highly doubt, as the same cable ran another camera fine for a month before I installed this one)... but i guess its possible its the cable.
Or bad PoE in camera (so direct wire 12v).

Also, if it were simply a Power issue, the camera should simply be rebooting, not hanging up first (as Q has seen, and I now notice). Camera simply become unresponsive for a period of time before rebooting. I have even once had it crash (didn't come backup up for 20+ min, so I power cycled it).

This to me speaks of Firmware/hardware issues.

 

[reverend]

Silly question but I've seen similar on the 59225 here and noted that it will drop the network side of things and RTSP will disconnect from Blue Iris but it will still happily write footage to the local microSD card. Do any of you having this problem use microSD cards to see if the 49225 is having a similar problem?

 

[reverend]

RTSP is for the video stream to software such as Blue Iris

 

[JayS_IPCams]

I've got a 49225 with the same restart problem. I can access it off and on for no longer than 24 hours, usually much less.
When I can't access it I first check to see if it indicates being "up" on my LAN using NIR's "Wake-Me-On-LAN" app:
WakeMeOnLan - Turn on computers on your network with Wake-on-LAN packet
, it usually is.
Then I try getting access thru the Dahua Config utility, after re-adding it, it sometimes gives access.
If this fails I cycle power, which always brings it back up - once I did a factory reset which worked.

I'm not using POE I've got a DC switcher power supply which is delivering 11.4 volts to the camera at the end of a 30' power extension cable.
Tomorrow I'll be changing to a linear PS which will be delivering 12.5 Volts to the camera (13.01 no load volts at the PS, ~0.5 volt line loss).

I'm wondering if there isn't some "keep alive" network pinging protocol which needs to be implemented from all the network protocols available on the camera, for instance UPnP's RTSP. Does anyone know what this protocol is for on port 554?

Sounds like you have the same issue as Q and I... maybe a bit worse. Mine usually comes back via rebooting its self. only once has it not rebooted. Let me know if the Linear PS works (i.e. making sure 12.5v is at the camera, as I have a 12v supply that would do the same as you, drop almost 1v at the camera, so is at 11.5v, however, at full 4Amps it stays at 11.5v, which i was going to try, but sounds like its a hardware/firmware issue in the camera

 

[Tinman]

The supply I have used for testing many cams outputs 12.34V. The cam wants 12V not 11.5. This is why a weak crimp or crappy cable can give you headaches.

 

[Nevvyn]

Hi Guys, long time reader, second time posting.. etc.

Anyway, I was partly relieved to come across this thread as I've been banging my head against exactly the same issue and I was beginning to think it was just me.

I was originally running it off a POE+ Switch, and when it "hung" it'd die until I rebooted it (by telling the port on my switch to shut cycle the power), it was always pulling the correct amount of power to be considered "on" but the web interface was unresponsive, and my NAS was unable to pull the RTSP feed.

I discussed this with the supplier, who upsold me a Dahua NVR (why the DVR would be different or better than a decent POE+ switch I have no idea, but I did like the idea of some of the extra features I'd get so I rolled with the punches on that one) alas the issue has continued. With the latest firmware that I found on the Dahua site:



The issue is still occurring. I have recording on 24/7 so I have been watching for gaps in the recording:



Above is with the firmware before this one 2018-9-13, and now:



So that's just this morning.

After each flash I have done a full factory reset on the device via the web interface (it's mounted so I've not been able to press any buttons easily) and re-setup the camera via the NVR, as per the Dahua instructions. I've not bothered with any fancy config on it yet bar a tripwire and an intrusion zone as I don't want to spend the time on the config until I'm happy it's stable.

The times today correspond with the following log entries:



and



If I delve a bit deeper and extract the logs that gives me:

15 System 16-12-2018 06:15:46 Start up {"Reboot Mark":"Exit"}
16 System 16-12-2018 06:15:03 Reboot {"Time":"2018-12-16 06:15:03"}

and viewing the footage says PTZ Restart in the top left.

Sorry for the huge swathe of data but in short I have now tried 12v Power, a "known good" POE+ injector, a "known good" POE+ switch, and a genuine Dahua NVR with POE+ on it. I'm defining "known good" by ports and devices that I have also used to power a Dahua Positioning Camera that draws more power and has been working fine throughout. I have been running both at the same time along with three other cameras but none of them are over the supply demands of either the NAS, or the Switch (or multiple injectors).

I think I will end up going down the route of attempting to replace this one under warranty, although the change in behaviour suggests to me that it might be fixable via firmware it certainly doesn't seem to be working.

Oh, and for flashing firmware, I've done it via crossover cable, via my lan network, via the NVR interface etc.

I might give the RS232 and TFTP a go, but it's not very practical next time an update is needed or available, and others don't seem to have the same issue.

Anyway, I'm glad it's not me, although I'm sorry not to be able to add any fix to the mix.

N.


Edit: From the original post -
1) Flaky Network.
I changed this too, made no difference.
2) Flaky POE injector.
Tried three different methods, no difference.
3) Camera drawing too much power.
Draws less than the positioning cam.
4) Flaky Camera.
This is where I am with my deductions so far.

Only step missing is, try new firmware.. it has made it slightly better, but still random reboots.

 

[looney2ns]

@EMPIRETECANDY Any word from Dahua on this issue?

 

[Tinman]

Reporting in on the results of supplying 13 volts (~12.5 volts at the camera): it stayed up for about 36 hours - then the usual no access.
It's not voltage or lack of it that's causing the problem.

BTW; I sometimes see a range of 95 to 135+ degrees F on the OSD display - could it be a temperature problem?
I've also got the OSD pan readouts all screwed up (East and West are reversed and North reads 98.3 degrees)

I hate to have to try another 49225 since my installation is a bear to put up and take down ...but

So you never replaced network cable or ends then ? just curious as you said your installation was a bear to take down.

 

[SkyLake]

On the playback page of the NVR / Camera, you can set check marks:


If i uncheck the motion check mark, i get a similar image, that looks like the cameras stopped, rebooted etc etc.


If i set Motion to enabled, the open spaces get filled with the corresponding motion recording.


Maybe that's the issue? At first, it seemed like i also had many restarts, but it actually recorded 24/7. It just replaces the green regular bar with the yellow motion bar. Maybe to prevent double data? Did you uncheck the Motion?

I can only look at the NVR in this case, as the camera's don't have sd cards in them at the moment.

 

[Nevvyn]

On the playback page of the NVR / Camera, you can set check marks:
View attachment 36523

If i uncheck the motion check mark, i get a similar image, that looks like the cameras stopped, rebooted etc etc.
View attachment 36524

If i set Motion to enabled, the open spaces get filled with the corresponding motion recording.
View attachment 36525
Maybe that's the issue? Did you uncheck the Motion?

Assuming that’s in response to my post, if so, alas that’s not the case, if you squint you can see the motion events are also there, but if I go to the video playback and play it just after one of the gaps it says “ptz restart” on the screen. Plus the camera log entries say it’s restarted itself (but don’t help explain why). And when they weren’t hidden behind the nvr, my network monitoring would say it’s lost ping to the device.

If that wasn’t in response to mine, ignore this.

 

[Nevvyn]

Silly question but I've seen similar on the 59225 here and noted that it will drop the network side of things and RTSP will disconnect from Blue Iris but it will still happily write footage to the local microSD card. Do any of you having this problem use microSD cards to see if the 49225 is having a similar problem?

I can confirm that in my case, although the unit draws power, it is not writing to the internal sd card.

 

[fenderman]

No, no need to. All cables have continuity.

continuity does not guarantee a good connection. Best way to test is a short premade cable. Also the cable must be good quality solid copper not CCA and wired using the 568 standard.