Pre-Trigger Record time

[TimG]

A very good post. May I suggest you write to Support ?

[Rantech]

Done. I'll post the response I get when received.

[IAmATeaf]

I honestly thought that the enforced 5 second pre-trigger time had been removed.

Now that you have lodged a ticket it could go one of 2 ways, profile 1 and 2 corrected to remove the default or the other profiles updated to also enforce the default delay.

Will wait to see what happens

[Pogo]

This forced delay is BS any way you cut it. The reasoning is to give Blue Iris a better chance of zeroing in on a keyframe for "better performance". Keyframes are typically only 1 ~ 2 seconds anyway, so BS.

It's worked fine until now. Suggestion for "Support": Find a better way to fix what wasn't broken in the first place..., or leave it alone. You're beginning to fall all over yourselves with 'development' at the expense of practical (and acceptable) user experiences.

I personally have had zero problems with sub-second pre-trigger buffers on anything of mine -- including three Reolink cameras.

[Rantech]

I’ve been using blue iris almost 10 years I think since ver 3.66 and have never experienced an issue with short pretrigger times either. Have been managing a half dozen different installs at some times. However, I’ve only ever used hikvision cameras or same under another brand name.

[Rantech]

Update on Ticket ... the 5 sec min pre-trigger record time is mandatory. The bug which may allow some profiles to escape this limit will be fixed in a future version so all profiles will apply the 5 sec min. The response indicated that many users were having problems when using direct to disc if the buffer did not contain a key frame and to avoid this the 5 sec min shall always apply. My take on this is that there are too many users who are unable to properly configure their cameras to ensure a key frame within their pre-trigger buffers so ....

[IAmATeaf]

Update on Ticket ... the 5 sec min pre-trigger record time is mandatory. The bug which may allow some profiles to escape this limit will be fixed in a future version so all profiles will apply the 5 sec min. The response indicated that many users were having problems when using direct to disc if the buffer did not contain a key frame and to avoid this the 5 sec min shall always apply. My take on this is that there are too many users who are unable to properly configure their cameras to ensure a key frame within their pre-trigger buffers so ....

Bit disappointed with the sledgehammer/nut solution, there should really be a I want to override the default 5 and take my chances option otherwise there is no point in actually having the option?

[Rantech]

I have noticed that many cameras I have bought recently come preloaded / configured so a Keyframe is only sent every 4 secs so I guess this is why BI has defaulted to 5 secs. I can see that the majority of casual users would not know to change the Keyframe rate (or know what they should set it to), but I thought an override with sufficient explanation in the software would be a balanced solution - make the option hard to find and clearly explain that the camera has to be set to a key frame rate less than the pre trigger buffer.

Actually, a more sophisticated solution would be as follows: BI already monitors the frame rate / key frame rate and shows this ratio on the real time camera info page. Allow the user to set a pre trigger buffer rate but then compare this to the data reported by the camera and over-ride the users input based on the actual key frame rate for the camera. That would be the elegant solution but would involve more complex programming.

[IAmATeaf]

I agree, BI already puts up an exclamation mark if the ratio is not 1.00 so this data could be used to enforce a pre trigger for that cam or warn the user that they need to do something!

I can see a lot of users with LPR cams potentially having to reconfigure things if and when they update and this 5 second rules comes into play.