Multicamera review hangs for LONG time

[Linwood]

I tested Xeoma a long time ago, and one thing I missed was a review (scrub back and forth) of more than one camera at a time. I reviewed, got a license (Thank you) but used a different product. I thought it was time to look again, and am happy to see a lot of new functionality including the multi-camera review.

But... I can't make it work in a practical sense.

I downloaded the linux x64 version and ran, and with a windows client accessing it, I added 7 IP cameras. They are producing 2048x1536 images at 4fps, and connecting over rstp. No problem.

I loaded this on a 4 virtual core VM running ubuntu 16.04.3, and removed all the motion detection so it continually records. In this way the CPU is running at about 5% -- virtually idle. Plenty of memory (of 8192G), and IO write from the video is running about 2-6 M/s, again very low load (this is running to a storage pool of 4 SSD's, no spinning disks involved).

So... very nice, then I tried the review, and selected all 7 cameras. I moved the slider, it moves easily. I picked a spot. Cameras shifted over time, but it too 72 seconds before all 7 cameras where near that time.

Moved it again -- this time about 12 seconds.

Again - about 8 seconds, and from then on it seemed to manage it in about 6-8 seconds.

But that's VERY slow.

So rather than trying to move the slider I set it to x10 speed. THe slider was a bit erratic but did run somewhere near that speed, but the images would individually hang for 5-20 seconds at a time, then jump. Very erratic.

And all the time doing this, IO hit maybe 10MB/s read, and the idle time hung over 90% -- definitely not CPU bound overall (though it may be single thread bound in some way, using a single thread to do all the cameras rather than parcelling it out?).

Am I missing some kind of tuning parameters or setup issues, or is the multi-camera review this slow?

With one camera it is a bit lethargic, but usable.

Thanks.

Linwood

[Linwood]

Actually even with one camera, I was experimenting with going back and forth across sunset (easy to see when the image shifts), and the fastest I can get a single camera to shift is about 3 seconds; that seems pretty long when you want to jump around hunting.

[Linwood]

I have tried this several more times, and the only thing I am sure of is that it is inconsistent.

Right now I can jump back and forth with 7 cameras in about 3 seconds. That's not great (compared to other tools) but is vastly better than what I saw the first couple times.

I can find no system aspects to account for it -- indeed, I've given it more cores (8 virtual) and memory (16G) just in case, it's really loafing. It's possible the drop to 3 seconds is related to more cores, but I certainly did not see any resource constraints in prior tests either.

Client and server are both on the same network, 1gb switch, no network delays. Camera settings (quality, fps, etc.) are unchanged.

Is there some kind of indexing or optimization that occurs periodically that may account for the wild variations?

[Admin_P]

Hello! Our Development Team is currently overhauling the archive's database to deal with the possible performance issues. The new version should do better.
If you'd like to be notified, when it's released, feel free to subscribe to our newsletter.