Event Convertion Specifier Discussion

I have in recent times received different requests and even patches related to how events are numbered.

Here are some of them.

• Add a new field to the SQL database with the event start timestamp - See SQLEventLogging patch
• Save the event number in file so that Motion continues where it left off.
• Make convertion specifiers for event time stamp.

I had actually accepted the first.

And I had rejected the latter because it makes using Motion more difficult (you now have to figure out where this file is stored, you have to get access rights right) and Motion needs to write to yet another file when Motion is detected.

The conversion specifiers requires that I drops many of the existing ones because we are out of latin letters. So it would be a very limited subset we would be left with.

The issue is that the event starts at 1 each time Motion is restarted.

So instead of trying to fix something that is really not good - maybe rethinking the event ID is a better option. So I was thinking of something like this.

• A new option text_event is introduced. You can use all convertion specifiers as you know them today. We will keep the %v for event because we will maintain such a number in the variable cnt->event_nr anyway because it it used for so many things. The text_event is an option that is used with a new convertion specifier (below)
• A new convertion specifier is introduced - %C is my proposal (currently represents the century and is 20 the next 95 years) . It represents the value of the cnt->event_nr or in other words the string that was defined at the time of the first motion detection in an event.

How can this be used?

Well let me give some examples.

Filenames could be built like this.

EXAMPLE 1
text_event %Y%m%d%H%M%S
jpeg_filename %C-%Y%m%d%H%M%S-%q

Would give filenames like this
20050710122405-20050710122405-00
20050710122405-20050710122405-01
20050710122405-20050710122405-02
20050710122405-20050710122406-00
20050710122405-20050710122406-01
20050710122405-20050710122408-00


EXAMPLE 2. Assuming gap >= 60 we do not need seconds in events
text_event %Y%m%d%H%M
jpeg_filename %C-%Y%m%d%H%M%S-%q

200507101224-20050710122405-00.jpg
200507101224-20050710122405-01.jpg
200507101224-20050710122405-02.jpg
200507101224-20050710122406-00.jpg
200507101224-20050710122406-01.jpg
200507101224-20050710122408-00.jpg

EXAMPLE3 Assuming we can cope with the year changing in the middle of an event and still gap >=60.
text_event %Y%m%d%H%M
jpeg_filename %C-%m%d%H%M%S-%q

200507101224-0710122405-00.jpg
200507101224-0710122405-01.jpg
200507101224-0710122405-02.jpg
200507101224-0710122406-00.jpg
200507101224-0710122406-01.jpg
200507101224-0710122408-00.jpg

EXAMPLE4 Why not have each event in its own directory and now dropping month part of filename
text_event %Y%m%d%H%M
jpeg_filename %C/%d-%H%M%S-%q

creates a directory 200507101224
with files
10-122405-00.jpg
10-122405-01.jpg
10-122405-02.jpg
10-122406-00.jpg
10-122406-01.jpg
10-122408-00.jpg

For the SQL part I can either add a text field in which you put this text_event OR I can put the event timestamp. I am not sure which is the smartest. There is a patch that implements the latter which I am holding back because I wanted this discussion first. Nothing prevents using text_event "%Y-%m-%d %T" as the string and having a timestamp field in the database.

Kenneth

-- KennethLavrsen - 09 Jul 2005

Comments

I like your suggestion very much.

I am a little confused by the use of %v vs %C in your description and examples though. My understanding of your description is that %v will have the same behaviour as previous versions, and that %C will represent the new event timestamp text. However, your examples appear to use %v for the new event timestamp text. Am I missing something?

-- TimWegener - 15 Jul 2005

---

You spotted a major mistake from my side. Yes it should be %C in the examples. I have corrected it.

-- KennethLavrsen - 15 Jul 2005

---

So is this going in? I think it would be good to have the 'text_event' feature and the 'put the event timestamp in the SQL database' feature. That way usable event information is available in both file system and database domains.

-- TimWegener - 20 Jul 2005

---

Yes. I just need to get back from vacation. I will implement it probably for a 3.2.3 release some time in September. 3.2.2 will be out in August and will focus on netcam code which is very broken in 3.2.1.

-- KennethLavrsen - 20 Jul 2005 / 10 Aug 2005

---

The %C conversion specifier is now implemented. There are a few small details that we either must accept or we will have to wait for some other changes.

The pictures in the pre_capture buffer gets timestamped today as they are captured. This is done so that the same timestamp can be used for films, jpegs and the webcam and so that we do not have to have even more CPU load when processing the pre_captured images. This also means that %C in text_left and text_right will not be seen on the images buffered by pre_capture and minimum_motion_frames. I doubt %C will be used much for image overlay text.

The filenames are correctly named because the filenames are not generated until the files are saved.

I have not yet decided what to do with the extra SQL field. Shall it be %C or a fixed SQL timestamp?

The %C conversion specifier is available on the 20050904 daily snapshot and forward.

-- KennethLavrsen - 03 Sep 2005

---

I think it should be an SQL timestamp. If you are using a DB backend you want the time data stored as time and then display it however you want in your presentation code. This would also be consistent with the existing frame time_stamp.

-- TimWegener - 07 Sep 2005

---

I just tried 3.2.4_snap2, and indeed you have using event_time_stamp of type timestamp (SQL), which is perfect. It worked straight off, as a drop in replacement for my patched version. Thanks for adding this feature!

-- TimWegener - 07 Sep 2005

---