[MERGED] Making rounding on Event Length optional
Posted: Sat Mar 20, 2021 10:28 am
According to my research based on this thread:
viewtopic.php?f=40&t=30598
I've noticed that according to the code, Events on continuous recording are saved on a rounding basis for function RECORD exclusively (this can be bypassed in the Motion Record alternative).
Not sure why this behaviour has been implemented on the zm_monitor.cpp, but I think that this should be optionally selected in the MISC section
1511-1514 zm_monitor.cpp
There should be a boolean variable that optionally permits also bypassing this on the RECORD function something like
If this idea seems legit (at least for me is crucial since I need to be saving 1 hour of continuous recording blocks not 1 hour and 55 minutes).
Maybe I could do the patch, although, I'm not 100% confident with the whole architecture (specially the likings of frontend->SQL->variable), but I'm certain this shall be pretty straightforward for anyone who manages the code with confidence. Nevertheless, if approved, I could give this a go.
viewtopic.php?f=40&t=30598
I've noticed that according to the code, Events on continuous recording are saved on a rounding basis for function RECORD exclusively (this can be bypassed in the Motion Record alternative).
Not sure why this behaviour has been implemented on the zm_monitor.cpp, but I think that this should be optionally selected in the MISC section
1511-1514 zm_monitor.cpp
Code: Select all
if ( section_length
&& ( ( timestamp->tv_sec - video_store_data->recording.tv_sec ) >= section_length )
&& ( (function == MOCORD && (event_close_mode != CLOSE_TIME)) || ! ( timestamp->tv_sec % section_length ) )
) {
Code: Select all
if ( section_length
&& ( ( timestamp->tv_sec - video_store_data->recording.tv_sec ) >= section_length )
&& ( (function == MOCORD && (event_close_mode != CLOSE_TIME)) || ! force_time_rounding || ! ( timestamp->tv_sec % section_length ) )
) {
Maybe I could do the patch, although, I'm not 100% confident with the whole architecture (specially the likings of frontend->SQL->variable), but I'm certain this shall be pretty straightforward for anyone who manages the code with confidence. Nevertheless, if approved, I could give this a go.