Felenasoft

Hello,

There is a behavior I have noticed and wanted to know if it is normal or as intended. Lets say there is a motion event captured at 10:02 and 25 seconds. I can see this in the xeoma console on the local computer which xeoma is running.
When I connect via web server, there is a dropdown to show what minutes contain motion events. If I select the entry for [10:02], the counter starts counting up from 10:02 and 0 seconds, 10:02 and 1 seconds, 10:02 and 3 seconds etc. There is no movement on the video up until 25 seconds, most likely due to the fact there is no video data captured during this time of 10:02:00 - 10:02:24.

Is this normal behavior? I would think that selecting 10:02 from the dropdown in the web archive interface should immediately begin playing at the point where motion was detected. There are times motion was at 55 seconds of the minute so I have to sit and wait 55 seconds for the counter to make it's way from zero in order to see the motion event.

Can you confirm if this is normal behavior and could it be changed with a setting?

thanks

Hello! Thank you for pointing this out, that is not intended behavior and requires fixing on our side (the web-archive navigation needs fine-tuning).

Hello,

I am glad to help. Is there any estimate on when this might be corrected?

I'm also seeing many selections in the drop down box of minutes which appear to have less than one second of motion (ie. I select it and seconds count up for a very brief amount of time and then it automatically increments to the next minute, while no video gets to be displayed. I have not investigated this myself yet (by checking at the local console) but wondering if you have seen this also? It may be tied into how the software programmatically decides if a motion event exists for a given minute.

still same error in 18.5.29

Works little bit better in latest 18.6.5 version after re-index archives. But not fully functionality yet. Still hang every ~3 video.

Does this problem appear in the Xeoma android app? I have not installed it and would rather not yet if it has the same issue.

Thanks

bump... Anyone? Is this problem evident in the Android app? and has there been any progress at correcting this behavior as of yet?

Hello! This behavior has been fixed, the next beta should display all the archives via browsers correctly.

Hello, thank you for the update. I see all uploads on the website as version 18.7.10 and showing a date of July 10, 2018. When will the new Beta version with this fix be available?

Psst, don't tell anyone, but the new version should be out this week
On a more serious note, we are testing the final pieces of the update: if the tests are all positive - the version is ready.

Still no updated beta. Being beta, I would think excessive testing is not necessary? Is there any update?

Can you at least give an ETA if this is not ready yet? I am trying to set something up for somebody else and need to know if this will not be available soon he will need to use something else.

thanks