Many and multiple 00:xx:xx points in archive

[catabrown]

Hello,

I am noticing a slight problem with the archive, despite the recent fixes you administered. For a given day, today for example, I have motion events as early as 00:00:23 at top of the list. I presume this means 23 seconds after midnight. There are motion events leading up to 18:59:31 near the bottom of the list and then there are a bunch of 00:xx:xx events listed after 18:59:31, and not in order. More visually, this is the pull-down choices:

[00:00:23]
[00:03:16]
[00:05:35]
[03:11:13]
...
[18:59:31]
[00:00:23]
[00:00:14]
[00:00:27]
[00:00:26]
[00:00:50]
[00:00:51]
...
[00:00:50]
[00:00:50]

It is currently 21:40, and I know there should be motion events since 18:59:31 but I cannot find them. There seems to be no data on the 00:xx:xx entries that follow 18:59:31. The 00:xx:xx entries at the top of the list work correctly.

Is this something you have seen before or are aware of? Please advise if there is something I should try, or if a fix is necessary.

Thanks

[Admin_P]

Hello! Try checking the actual files for this archive for the specified time period (the path is in Preview and Archive settings). Do the files for this period exist at all? If so - go Archive menu -> Reindex the archive.
If the recordings are still inaccessible:
1) stop Xeoma (-stopservice)
2) access Xeoma's main folder, XeomaArchive directory
3) rename the file Archive.db
4) launch Xeoma (-startservice)

[catabrown]

hello --

There are files in 2018-12-30, however the latest file appears to be 18:59. Please see below output of files in 2018-12-30 directory:

-rw-r--r-- 1 root root 16M Dec 30 18:56 1436_00_23.xem
-rw-r--r-- 1 root root 3.2M Dec 30 18:57 1436_54_03.xem
-rw-r--r-- 1 root root 29M Dec 30 18:57 1437_00_34.xem
-rw-r--r-- 1 root root 7.0M Dec 30 18:58 1437_51_08.xem
-rw-r--r-- 1 root root 18M Dec 30 18:58 1438_00_24.xem
-rw-r--r-- 1 root root 17M Dec 30 18:59 1438_34_25.xem
-rw-r--r-- 1 root root 36M Dec 30 19:00 1439_00_52.xem

However, the "missing" videos do exist because I am able to see it when watching from the local console (by running xeoma.app) -- This problem only exists when connecting via http and using the web interface. I am able to watch beyond 18:59 on the local console using the .app file.

I believe I know where the local app is obtaining the file data from. I see there is also a 2018-12-31 directory. The date 12-31 does not exist yet (and I checked my clock is set correctly.) Files in that directory are stamped beginning 19:00 on 12-30. See below output of files in 2018-12-31 directory:

# ls -lah
total 2.6G
drwxrwxrwx 2 root root 8.0K Dec 30 21:52 .
drwxrwxrwx 10 root root 150 Dec 30 19:09 ..
-rw-r--r-- 1 root root 46M Dec 30 19:01 0000_00_59.xem
-rw-r--r-- 1 root root 4.6M Dec 30 19:01 0001_00_05.xem
-rw-r--r-- 1 root root 3.3M Dec 30 19:09 0008_52_03.xem
-rw-r--r-- 1 root root 22M Dec 30 19:14 0014_06_24.xem
-rw-r--r-- 1 root root 4.7M Dec 30 19:17 0016_51_05.xem
-rw-r--r-- 1 root root 28M Dec 30 19:22 0022_02_34.xem
-rw-r--r-- 1 root root 9.2M Dec 30 19:23 0022_47_12.xem
-rw-r--r-- 1 root root 11M Dec 30 19:23 0023_00_12.xem
-rw-r--r-- 1 root root 3.2M Dec 30 19:28 0028_40_03.xem
-rw-r--r-- 1 root root 3.8M Dec 30 19:29 0029_30_04.xem

So I guess two questions -- What are the small 00:xx:xx files in 12-30 and why is footage after 18:59 being stored inside the next-day directory before that day exists?

All cameras have this same issue. Interesting thing is, on the drop-down for time events when using the web interface, 12-31-2018 does not show as an option, however I can see that the 2018-12-31 directory has already been created and holding data.

Have you seen anything like this before? Perhaps it is some kind of timezone issue?

[catabrown]

Oh also, can you point me to where the reindex archive option is? I can't seem to find it.

Thanks

[Admin_P]

The archive's files and folders are named based off UTC (independent of the server's timezone), so folders "from the future" in your given timezone are normal behavior.
Short files usually indicate one of two things:
1) recordings are kept based off a detector (e.g. if Motion Detector reacted for only 8 seconds - the resulting file will be 8 seconds long)
2) the connection with the camera is unstable and gets interrupted often; you may want to try setting TCP as Transport protocol type in the Universal camera settings
For reindexing - see screenshot.