5.4.4.0 update - new triggered+continuous record setting

[105437]

This should really save on disk space requirements for 24/7 recording I would think.

Update Notes - 5.4.4 - April 27, 2021
When the triggered+continuous record mode is used with a dual-streaming camera along with
direct-to-disc, the result is a BVR file which will contain the sub-stream continuously
recorded, but the main-stream only recorded when the camera is in a triggered state.
During main-stream playback, the sub-stream will be upsampled whenever the main-stream
is not available.

The DeepStack detect/ignore static objects option will now force a re-analysis of the image each
10 minutes when not triggered in order to refresh the static objects collection.

 

[tward392]

I started getting a lot of the following after updating to 5.4.4 so I went back to 5.4.3.12, I also sent a message to support@blueirissoftware.com.

2 4/27/2021 4:51:28.447 PM Export Source file format is corrupt or you are missing required components.

Please use the default BVR recording format or install the basic K-Lite Codec Pack which is recommended for MP4/AVI support (see Help FAQ).
0 4/27/2021 4:51:28.574 PM Shed Email: blah_blah_blah@gmail.com with 4 attachment/s
3 4/27/2021 4:52:06.499 PM Shed MOTION
0 4/27/2021 4:52:07.333 PM Shed DeepStack: person:54% [3140,1026 3593,2142] 577ms
2 4/27/2021 4:52:12.412 PM Export Source file format is corrupt or you are missing required components.

 

[wittaj]

I tested this with one camera overnight to see how it works.

Previously, I would get about 1 hour at 3.90GB with the camera recording 24/7.

With this new feature, I got 1 hour at 120MB.

That is a tremendous savings!

As always YMMV. Obviously bitrate and FPS come into play, but it is yet another feature that can allow for higher resolutions with less storage needs.

 

[erkme73]

I started getting a lot of the following after updating to 5.4.4 so I went back to 5.4.3.12, I also sent a message to support@blueirissoftware.com.

2 4/27/2021 4:51:28.447 PM Export Source file format is corrupt or you are missing required components.

Please use the default BVR recording format or install the basic K-Lite Codec Pack which is recommended for MP4/AVI support (see Help FAQ).
0 4/27/2021 4:51:28.574 PM Shed Email: blah_blah_blah@gmail.com with 4 attachment/s
3 4/27/2021 4:52:06.499 PM Shed MOTION
0 4/27/2021 4:52:07.333 PM Shed DeepStack: person:54% [3140,1026 3593,2142] 577ms
2 4/27/2021 4:52:12.412 PM Export Source file format is corrupt or you are missing required components.

Just chiming in to say, me too. Every time I have an external trigger on my gate camera, I get the same source file is corrupt notification. Let us know if you hear back from support.

 

[tward392]

Just chiming in to say, me too. Every time I have an external trigger on my gate camera, I get the same source file is corrupt notification. Let us know if you hear back from support.

They responded with "Got it."

 

[wittaj]

I just tested one of my cameras that is externally triggered and it works as expected.

 

[sebastiantombs]

Anyone notice long time lags when playing an alert back using UI3? Mine work fine on the console, but on this laptop there is a significant delay, on the order of seconds perhaps as much as 10. It does seem related to resolution of the camera. The 2MP are pretty quick, but the 4MP can be really slow. I'll have to try UI3 on the BI machine and see what happens there.

 

[erkme73]

I just tested one of my cameras that is externally triggered and it works as expected.

I wonder if it has to do with the alert camera sending an MP4 when it fires. My exterior trigger sends a push notification to the app, and an email with 3 stills and a 15 second clip. That's the one that does the error, and the email does not contain the clip.

 

[wittaj]

Oh that could be - mine just sends a picture.

 

[erkme73]

Yeah, I think that may be the common denominator. I'll send a note to Ken if it doesn't clear up with the next release. Not only is it an error, it is effectively killing the "send video clip" with notification.

 

[erkme73]

Latest update resolved the issue...

 

[MicahJames]

This has been really helpful for saving space but I can't seem to figure out how to change the amount of Main Stream recorded before the trigger.

My first thought was to change the pre-trigger buffer but even at 10 seconds it doesn't effect the recording.

Currently I'm seeing sub stream up until the very second of the motion event which kind of sucks for seeing a little bit of what happened before hand in full resolution.

Any ideas?

 

[wittaj]

It appears from the help file that this is normal behavior. It doesn't specifically state it, but it does say that the pre-trigger only works for the triggered state.

I have been testing all these new features one at a time and I didn't notice this at first because I tried it with my PTZ, but the spotter cams would turn the PTZ so by the time it turned, it was back to mainstream.

Hopefully this is something he will be able to figure out in a future update. I sent him a request, so maybe if a few others do, he can see if there is a solution.

 

[Dave Lonsdale]

I tested this with one camera overnight to see how it works.

Previously, I would get about 1 hour at 3.90GB with the camera recording 24/7.

With this new feature, I got 1 hour at 120MB.

That is a tremendous savings!

As always YMMV. Obviously bitrate and FPS come into play, but it is yet another feature that can allow for higher resolutions with less storage needs.

You’re right wittaj, a tremendous saving. However, according to Murphy’s Law (in the UK it’s often sod’s law), most of us record 24/7 because the very clip we want at top res happens to be the one that was missed. My 8TB is overwritten every 7 or 8 days, so an alternative that delivered say a 50% saving with a more secure result would be brilliant. I am wondering if you guys could figure out a better compromise. Despite expecting to be shot down in flames, how about either:-
1). Use the highest res available from substream 2 (Dahua) or the third stream (Hik) with a decent bitrate and cope with the increase in CPU. This would also help those who want to use facial recognition.

or:-
2). Ask Ken Pletzer to handle three streams. Main stream recording direct to disk when triggered and third stream recording direct to disk the rest of the time as in 1) above but then only use the normal substream to process the triggers as at present to keep the CPU low.

or:-
3). Ask Ken Pletzer to add another option to record triggers at top res and the rest of the time only record every other or third frame but at top res/bitrate so as to half the number of bits recorded nearly all the time. Substream used as at present. I can imagine the rate of frames dropped may need to vary to avoid an unfortunate coincidence with every iframe. This would be my favourite if something on these lines is possible.

3). Some other compromise, saving at least 50% hard drive space.

 

[wittaj]

@Dave Lonsdale - that is true!

I haven't officially gone this way yet and still testing, but I could see myself doing a mixture until I am comfortable.

I too record 24/7 just in case, and I have my system set up fairly good that I do not miss motion in my critical areas, so these cameras could benefit from this.

My overview cams also record 24/7 in the event something happens that a neighbor wants to know if I saw anything. However, those events are at night and even with a higher resolution, a 2.8mm overview cam on a 2nd story isn't going to make out details 120 feet away regardless of the resolution (at least in my situation where there are no street lights).

I do think that for moment, your option 1 of using a higher resolution substream is probably the best bet.

I also think this benefits those that are only recording based on triggers - one could now record 24/7 with out a substantial storage load.

 

[wittaj]

So it seems the latest update is going the other way and is causing a longer delay now switching to mainstream than before.

Previously, it would switch to mainstream what I believed to be the next Key frame, so in my one camera, when a vehicle was about halfway in the image it would switch to mainstream.

Now the car is completely gone from the frame before it switches to mainstream.

The heading also changed from triggered+continuous record mode to triggered+alerts record mode, so now it appears to be going thru DeepStack to get the alert back before changing.

Edit - I just turned DeepStack off on that camera and it reverted back to switching when the vehicle was halfway in the image.

 

[sebastiantombs]

So much for saving disk space. That isn't very good at all, IMHO.

 

[wittaj]

So much for saving disk space. That isn't very good at all, IMHO.

It's a work in progress. Once it can switch to mainstream for a pre-buffer, it will be a great savings.

I will probably take a few of my overview cams to this and a few of my Dahua AI cams as the savings is rather large.

I sent off an email.

 

[sebastiantombs]

Can't argue with the amount of space saved, it's the cost of losing resolution when you need it most.

 

[drjjr]

So I thought I have my camera set up correctly. It shows both main stream and sub stream in the General tab, I do not have "triggered+continuous" as an option for recording. I do have "continuous+alerts"
I do have "record dual-streams if available" checked.
What do I have wrong?