ZoneMinder Forums

Hi,

I use zm 1.32.3 with gentoo.
In my system I use a SSD to save the actual events of my 8 Reolink-Cameras.
Because the SSD is only 1TB and I want to save the events 2 weeks I use a additional SATA-Drive
with 5TB.
To move the events from SSD to SATA I created a filter

| 25 | MoveSSDtoHDD | {"terms":[{"attr":"DiskPercent","op":">=","val":"50"},{"cnj":"and","attr":"StorageId","op":"=","val":"2"}],"sort_field":"Id","sort_asc":"1","limit":"10"}

After the Video was moved an If the move was not on the same day the event is created
(storage scheme is medium) the event Start-Times changes in Database to the "copy" date
and will not be found by zmconsole on disk

MariaDB [zm]> select ID,StartTime,EndTime,Frames,DiskSpace from Events where id = "82896";
+-------+---------------------+---------------------+--------+-----------+
| ID | StartTime | EndTime | Frames | DiskSpace |
+-------+---------------------+---------------------+--------+-----------+
| 82896 | 2019-05-03 04:50:22 | 2019-05-01 18:42:55 | 34 | 141254665 |
+-------+---------------------+---------------------+--------+-----------+

Maybe the "Update Disk Space"-Filter did this "Job"?!

Is it possible that ths the "move" is a "copy" (new file on Disk) and so the "update Disk Space" will
change the creation date ... and later on delete teh event?

Hope someone can help

Regards
gentoo

No. Nothing in the filter will change the StartTime.

When doing the move, the file is copied, and only if successful will the source files be deleted. So the creation time of the files may change, but NOT the db record.

In zmaudit, there is some code to reconstruct an event db entry from the files, but this SHOULD NOT be happening. It would require the db record to be deleted.

Make sure that zmaudit is turned off, it is not required for normal operation. CHeck zmaudit logs, then will be stuff logged about event reconstruction if this is the case.

Hi,
Thank you for your reply - I disabled zmaudit now ... will keep watching
regards
gentoo

Disable zmaudit did the trick - no more events are lost

First off my apologies on reviving an old thread but I am seeing the same behavior on CentOS 7

So with the zmaudit disabled you can't use the fast delete correct?

I've disabled the fast delete for now and also disabled the zmaudit because I also move things off to cloud storage once it reaches a certain age. But the dates were showing the start date as the date that it was moved and then the end date being the date that the recording originally ended on. Thank you for your help and this awesome software.

As you can see in this the start date is now listed as today but the end date is the original end date of the recording.

I've disabled zmaudit in the configs but its still changing the date to the wrong date.

EDIT: Also once it has that date mixed up in the system the recording can no longer be played.

EDIT2: Didn't realize that zmaudit after disabling it was still running so I did a kill -9 on the PID of the script and I'm hoping that this will now take care of this.

Has this been resolved or is there a bug report?

When I used a filter to move events it changed the displayed start date and copied the event to the new store, but wrote it to the an unexpected directory.

The log entry:
Can't create frame images from video because there is no video file for this event at (/zm/store3/5/2019-12-26/214077/214077-video.mp4)

I found the event in /zm/store3/5/2019-12-25/214077/214077-video.mp4 (This directory matches the UTC date of the event, not the CST date of the system)
The start time in the GUI changed to UTC time, the end time remained correct CST.

I moved the event to the expected path and I am able to view the event, but the start time is now UTC.

Ubuntu server 18.04
ZoneMinder 1.32.3