@jrbeddow,@Wildcat_1 The same issue with Corridor mode exists on the 5241 I use as a front door camera. IVS only works in the normal "horizontal" mode.
IPC-T5442T-ZE IPC-T5442TM-AS IPC-T5842T-ZE SMD 3.0 Smart IR Latest New Firmware From EmpireTech
- Thread starter EMPIRETECANDY
- Start date
Thanks for the confirmation, even if it is disappointing to hear. I will wait to see what @Wildcat_1 finds in regards to the 5442 cameras, but it isn't looking promising. Ugh, I suppose I could run DeepStack on that one corridor mode camera only, but I was hoping to be able to run only with the built-in A.I. IVS on all of these cameras. Unfortunately I am also finding the SMD function to be far too sensitive to changes in light levels as well (false triggers).
@jrbeddow are you seeing the SMD issues in corridor mode only ? I'm finding the SMD to be more on point as I mentioned in my testing. Will test all in corridor as well and will document everything in case needed for a bug etc
To be honest, I have only tried SMD as a last resort on that one camera I have rotated, as I have had good results with IVS rules on my other cameras (in normal horizontal orientation), so I had no need to try those in SMD mode.
I think I found a bug for my 5442 turret with the new firmware. I have set my night exposure to shutter priority customized range 0 to 25ms multiple times and it keeps resetting to 0 to 40ms (and of course at 40ms it is blurry video).
I think it may be resetting upon switch from day to night mode based on time schedule (within the camera settings), but I haven't confirmed that yet.
I'm getting a bit frustrated with Dahua over the past year or so. The Android mobile app was not working at all for a week or more after an update they made, then my NVR would randomly restart until I updated the firmware when it hadn't auto restarted for two years before, and then my 5442s started auto restarting recently until this new firmware. But now, this issue of settings not holding despite me defaulting settings and manual rebooting before and after every step for the firmware updates. I'm losing trust in the reliability for security use.
I think it may be resetting upon switch from day to night mode based on time schedule (within the camera settings), but I haven't confirmed that yet.
I'm getting a bit frustrated with Dahua over the past year or so. The Android mobile app was not working at all for a week or more after an update they made, then my NVR would randomly restart until I updated the firmware when it hadn't auto restarted for two years before, and then my 5442s started auto restarting recently until this new firmware. But now, this issue of settings not holding despite me defaulting settings and manual rebooting before and after every step for the firmware updates. I'm losing trust in the reliability for security use.
I’ll mock up this scenario to and test this along with @jrbeddow issue above and report back
The bug is on this version fw after you update it? Or on all firmware?
The firmware keeps updating, this mainly to help the camera to be a better one, like this 5442's old IVS more bugs and now we make it working better. Booting can be network or power issue, also maybe the NVR have problem.
Following up on this one (IVS in corridor mode). I tested the corridor mode on 5442s and 5842s on latest FW and can confirm IVS does NOT trigger. I’m going to test against other FW including beta base code FW and see how long this one has been rooted in code and will get the info together with code and will feed this back so it can be looked into.
Correct, this bug of not holding the shutter speed range setting only happened after this latest firmware. I updated to this firmware to fix the random rebooting problem and now I have blurry night video unless I manually fix the shutter speed each day when the setting is lost.
None of my older cameras using the same POE switches (way below max power per port and in total) and same NVR auto reboot, just these two 5442s. And since this new firmware, no more auto rebooting, so it seems to be the firmware versus my equipment (which hasn't changed in years). All equipment also on big battery backup, so no power loss (and power would have impacted all cameras versus only two).
Same lost settings issue on my fixed focus 5442 after looking tonight. So both my varifocus and fixed 5442s are losing the shutter range settings. It seems to hold the setting even upon reboot, but my hypothesis is maybe upon scheduled night to day to night is loses it.
I use manual settings and always recommend it that way rather than priority modes but will test with Shutter Priority to mock up your scenario and report back on my findings
Well, I spoke too soon @jrbeddow. I went back down the FW stack to 21-07-09 and saw it working without issue there. Then did my factory reset procedure I've shared before in between each FW load and went up each step through 21-09-30 then to 21-11-05 and all still working then did the reset procedure again and went to the latest 22-02-18 and its working fine both in local and in NVR recording in corridor mode (Flip 90 degrees). So whether there was a glitch in the factory reset the first time I tested or not but now working without issue at all. I will say corridor mode is certainly a slower response on IVS rules so will document that part for sure but works on Trips and Intrusion. When did you pickup your 5442, trying to ascertain revision (v1 or v2) etc as I'll try this on a number of others to check. Separately I still see the issue for 5842 but as that hardware is addressed differently in code I'll do some more separate testing there.
Following up, I have a couple of cams set for your exact Shutter Priority settings and scheduled for day/night via profile management time based shift. Will leave this through the night, watch it after switches to day and then back to night and report back. Let me know any other settings you have for day as well and I'll aim to have this test be as close to yours as possible
Thanks! Day is set to shutter priority range 0 to 35ms. Most of my cameras I set to manual, but I seem to remember this one had an issue during certain morning or sunset hours with sun angle and I switched to the range. When I did the default before and after fw update, I did the first one that didn't clear IP address. We'll see what your testing shows and whether I need to do the full default option and re-do all settings. I didn't import any settings, I did all except IP and user account from scratch manually to avoid the weird risks if you don't (wish it wasn't so finicky, but oh well )
As I mentioned previously, the manufacture date of this 2.8mm fixed lens 5442 is 06/2021, purchased in December 2021. I have done a second round of Factory Reset followed by reloading the same Feb. 18 2022 firmware, but have only done limited testing since then. For now, I haven't seen the anomalous "Isotherm Filter" setting on the IVS Global setup page (that I sent the screenshot of previously), so that is encouraging, but I haven't seen any performance improvements with regards to IVS behavior, and I still saw spurious false tripping with light level changes when using SMD.
At the moment I am trying to move all my equipment from a bench test environment to it's final permanent locations around my house, so everything is disassembled temporarily.
How much slower were the response times you were seeing in IVS under rotated conditions? From .5 seconds to 1 second? I could deal with that, but if it takes several seconds to spot a person walking, that's quite slow indeed, and I might have to look at other solutions (Deepstack).
Edit: By the way, do we have a good handle on when the changover took place in manufacturing revision? Late 2020, Early 2021, or ??? How do we go about confirming the revision number?
I have an unboxed fixed 2.8 that I will test against now. Tested and retested varifocal 5442's + 5842's (turret + bullet) and those test clean per above, no problem after going through the process I listed above. I will setup the fixed lens now and retest again. With regards to the IVS in corridor mode I found that in that mode it could add about another second or so in other words if you saw a regular .5 to 1 sec max (after rule breach) in normal (horizontal) mode then in corridor mode it would become 1.5 to 2 seconds BUT this is critically dependent on FW version too. More on this in a minute. So then I wanted to take this test further (all of this testing is in corridor mode) and so setup some other scenarios and reached an interesting conclusion. Specifically, in FW's (even early releases) that DO have more of a delay, what is interesting is in further testing I see that the target filter component adds its own delay as well. In other words if you walk into an intrusion zone, the recording can start quickly (usually within the .5 to 1 second range) BUT the target filter (Human or Vehicle etc) + associated target box (triggered by rule breach) is delayed a little further. Tested this on multiple cams so will be filing this as a target filter / rule breach alarm bug. Will also be testing on whether this impacts the recording time on breach vs filter processing
With regards to manufacture date of V2's, for vari-focal 5442's this started at the end of 2020 (cams with December 2020) and was more prolific in January 2021. Therefore for those around December you could have received a V1 or V2 but those with a Jan 2021 manufacture date are more likely to be V2 from that point on. Not sure on the fixed version though as due to different internals that may have been later AND may not have seen the same changes as its vari brother. Will see what I can find out
Quick Update on Fixed 2.8 5442 Specific Testing
Again went back to 21-07-09 and while IVS rules worked, there was a delay seen here too. Moved cam to 21-09-30 and that has been the snappiest (so far on fixed testing) in terms of IVS (including target filter) for the fixed camera in corridor mode. I'm now going to test 21-11-05 and then the 22-02-18 as well. Either way wanted to share my results so far of this corridor testing and as mentioned, IVS rules do work on these releases so far but with the delay mentioned. Will report back later on the other FW's I'm testing now
HTH
So far mine switched back to day based on normal schedule and didn't lose the shutter range today, so we'll see when it switches to night (night has been the main issue of losing the setting and going back to 40ms).
I'm guessing your test rig was also fine going back to day and 35ms as well?
Checked the recording (constant) around that time and yes switched without issue so cannot replicate this one. I setup a number of cams last night to test this and all switched fine. Will also check tonight as well
As always, another amazingly detailed response and thorough testing procedure. Bravo and thanks for looking into this, I look forward to your final (ahem
, as just when is software ever in a FINAL state?) conclusions on this subject.I still find it intriguing that your initial analysis agreed with mine, that IVS seemed to be be broken when using a camera in corridor/rotated mode. Does this mean that I just need to do several more rounds (2, 3, 4?) of the reboot, factory reset, and then flash the same Feb. 18 2022 upgrade to get it to finally "take"?
As always, another amazingly detailed response and thorough testing procedure. Bravo and thanks for looking into this, I look forward to your final (ahem
I still find it intriguing that your initial analysis agreed with mine, that IVS seemed to be be broken when using a camera in corridor/rotated mode. Does this mean that I just need to do several more rounds (2, 3, 4?) of the reboot, factory reset, and then flash the same Feb. 18 2022 upgrade to get it to finally "take"?
Hey @jrbeddow thanks for the kind words. With regards to the piece about analysis agreed with you, Yes BUT remember a) I was testing on vari's not fixed (which may or may not play a role once testing is complete) and b) I did then re-approach from a 21-07-09 FW and apply my reset procedure before and between each FW upgrade. In other words the initial analysis was on a vari cam running 22-02-18 (5442 and 5842) without doing anything more than trying to enable corridor mode. 5842 is still broken now in corridor mode so once I complete the 5442 fixed test will then re-approach that. So it could be something was stuck from the previous move to 22-02-18 that was not cleared initially. Therefore, YES my recommendation to you would be to follow my factory reset procedure before you then re-flash. No need for you to go back down the FW like I am doing (unless you want to or unless I find something else) but if you decided to do multiple FW tests then remember to factory reset before you re-flash and after it completes. If you still see the issue (which I am not so far based on above, remember on the fixed I'm just testing 21-11-05 now as 21-09-30 was the snappiest in earlier FW's) then let me know and we can discuss your config etc.
Will report back later on my findings with 21-11-05 and 22-02-18 on the fixed
HTH