Felenasoft

Hi there,
searched the forum, online help etc but could not find a resolution so far. Newest Xeoma SW installed, registered (standard), test running with 1 HIKvision 4K cam, providing two streams, substream for live view and H256+ for direct recording. Movement detection and archive module configured right:
- The movement sensor shows recording upon movement but the live view does not show "recording" upon movement (upper right corner, such as shown in manual)
- The Archive has been changed from C://users/documents/... to an external HDD. New folders are created but the DB / Metadata files remain in the Xeoma folder ind users/docs/public/xeoma...
The system won´t record anything
Is there any other user guide / any settings I shall be aware of?
Thanks : )

One more question: What´s the typical delay when showing the low res video substream from my cam in the live view? I experience at least a 2sec delay, but the same stream shows with <0.5sec delay in VLC...

Hello! We've just discovered a problem with "Motion Detector" on the beta version (18.4.5), please try using the release version (17.11.24).
Archive.db remains in the usual directory, it does not move with the archive itself. If you want to store it in a different directory, you can use the customization tool (parameter <ArchiveDataBaseDirPath>).
Delay is often caused by buffering, try turning it off in the "Universal camera" settings (checkbox Buffered video stream reading).

Thanks, Admin
version 17.11.24 works better. Customization tool looks good. This will probably help connecting the external HD to a powerful machine to browse through recorded video...

Just want to hear your feedback, please - as you are quite heavily promoting the Rasp. PI solution.
My HW: an Intel J1900 mini PC with SSD and 4G RAM (no h264/h265 HW support, unfortunately)
1 DS-2CD2085FWD-I installed, currently providing H256+ 10fps @8MP (mainstream) and Mpeg 640x320 at 15fps (substream)
Xeoma core load (with direct saving to HDD): around 30%; if client enabled: 60%; even with pre-recording and buffering, RAM is not critical at all. Same with Network.

Issue with Movement detection on (and pre-record off): Delay is 5sec+ and the pictures recorded do not catch the movement before it´s over. I am satisfied with the settings (area, size of object and sensitivity).
Issue with Movement detection on (and pre-record on): The situation ain´t no better. Still, the video is not recorded early enough - and the CPU load is up to 80+
Issue with direct recording and movement information stored in DB: The sensitivity of the movement is completely different during night and day. What triggers recording at 30% during day means continuous movement during night (0-60%). Every minute (file saving interval), there´s a peak too. This means the function does not at all work in my standard setup.

I am frustrated, thought a mini PC would do the job and don´t want to invest in a Hexacore, adding another 30W+ to the system. Searching the archive is a nightmare and a remoe client does not really help here...

I don´t expect a long reply at all - I would just like to know whether the HW I use is suitable at all and whether you can give me a hint reg. above mentioned settings, please

Thank you!

There is one more type of buffering you can turn off to try and decrease the delay: Layouts menu -> Disable buffering on the client side. If the situation remains, you can go Layouts menu -> Client decoding settings and choose Disabled for Video decoding on the client side for live preview.
Concerning the detector's accuracy: the stream it analyzes is the substream. Since it has lower quality, it's understandably harder to fine-tune the detector to react to things you require (especially, in night mode). However, you can split your chain for day-night cycles using 2 "Schedulers" and 2 "Motion Detectors".
As you have figured out, it ultimately boils down to hardware. A high-quality stream for the preview allows for more accurate motion detection (better picture to work with) but eats up CPU. Lower quality preview stream saves CPU but isn't quite as reliable in terms of motion detection.

Bottom line: if you prefer to use this hardware - you'll need more careful fine-tuning for the detector. If you prefer a simpler (less time-consuming) tuning - you'll need a more powerful server to handle the load.