Page 1 of 1

Issue with lag in archive

PostPosted: Tue May 01, 2018 5:02 pm
by catabrown
Hello,

I have Xeoma set up and running well in a linux environment (Fedora 27) - Everything runs well in real time. When I try to use the archive feature and select a time where motion was detected there are long lags of time before video is played. for example I could select a time when there was motion and the video will show the first frame of the motion while the seconds counter keeps counting up. It is sometimes upwards of 50 seconds before the image starts to play as video. Other times motion in the video frame never begins.

Is this a bug, or a problem you've seen before and what can be done to correct it? I have purchased a license for 4 cameras and want to rectify this before purchasing licenses for any more.

Thanks
Alan

Re: Issue with lag in archive

PostPosted: Fri May 04, 2018 1:10 pm
by Admin_P
Hello! First, I'd like to point out that Fedora is not officially supported, so things going wrong on it is not something unexpected. We do support a number of Linux distros listed here.
However, you can try downloading the beta version 18.4.24 (if you haven't already) - among other things it includes fixes for archive playback. Go Main menu -> Information -> Check for updates -> Update to beta versions.

Re: Issue with lag in archive

PostPosted: Sat May 05, 2018 1:54 pm
by catabrown
Hello, thank you for the response. I understand the impossibility of troubleshooting an unsupported OS. I have installed Ubuntu 14.04 LTS on the same hardware and tested. The same issue remains. The example:

* One RTSP camera watching an area
* Only modules in chain are camera --> motion --> preview and archive.
* Confirmed it was not [REC].
* Created motion at about 9:03:30 and saw it switch to *REC, so I know it was recording
* login from the local computer to localhost:10090
* selected 9:03 from the motion event dropdown* Seconds begin counting up from 0:00 up to 46.670. No motion is ever shown so I assume the "video" was a static frame of the first image the entire
time. However the motion only lasted about 15 seconds so it makes sense that it stopped at 9:03:46
* I tried the above twice and got the same result.
* I downloaded 9:03am to 9:03am and played the video file in a viewer and no motion exists in the video (just the same (What appears to be a still) image
* I attempted to view 9:03am inside the xeoma interface (not using the web browser) and blue marks indicate motion is present but no motion is displayed on the screen, but the seconds do count up.

* I created motion at 9:20am and everything worked correctly for that instance, so this appears to be some kind of intermittent issue.

I have doubts regarding the network as the culprit because Xeoma is aware there was motion (the dropdown list is populated with the correct minute motion existed and the bar on the bottom inside of Xeoma software shows blue marks that identify that motion exists at that time)

The hardware is an HP Proliant DL380G6 server running Xeoma V17.11.24 Trial Standard edition (I did not want to register and cause an issue with my already licensed and activated machine)
I could try upgrading to beta version but I have been having this problem for months ever since I started using Xeoma so thought beta could make troubleshooting more difficult being that all routines in it are not completely tested and validated as running correctly.

Is there any more tests I can do to help you identify the problem? Or some kind of debugging file info I can provide to you? I am using this test machine with Ubuntu explicitly to troubleshoot this problem, so I can run any tests or attempted solution you suggest. There is no data on the computer that I need to retain.

Thanks
Alan

Re: Issue with lag in archive

PostPosted: Mon May 07, 2018 2:59 pm
by Admin_P
Here is what you can do:
1) make a motion that lasts about 30 seconds or more
2) access the folder containing the archive (it is indicated in the "Preview and Archive" settings)
3) check the names of the .mp4 files: number-of-the-minute-from-day-start_number-of-second-in-that-minute_duration-in-seconds (N.B. time is UTC)
4) are the names consistent with the actual time?

If there are any inconsistencies or file duration is too small (<10 seconds) - try the beta.