Wrong Date & Time on some Recordings

[Gerwin]

Hello!
Since a few Versions i see a strange behavior on two different BI Setups running on Version: 5.2.7.12:
One Setup has 4 identical Cameras (SV3C 1080p) and the other 6...
In each Setup there is ONE Camera, from which BI records the Clips with wrong date&time . But not always, only from time to time, see screen:
Click Thumbnail->

You see the Cam "bub-Kassenbereich" behavior: the recordings on this screen are one timeline from bottom to top as you can see but the first and the third are two days in the Past aacording to BI?
On the second system i have the exact same problem with ONE Camera. The remaining cams are all working fine on both systems.
I checked all settings of each Cam, they are all the same. The internal System Date and Time Setting of the Cameras is also correct, they are on same firmware. Date and Time in Blue Iris Interface is correct.
I really dont know, where to look, does anyone know a solution or maybe have the same Problem?

Regards from Austria!
Gerwin.

 

[NielK]

I have what looks like the same problem: a clips list that shows invalid date/time/duration values for some of the cameras, even though the viewer displays the correct date/time/duration when I view the clip and the recorded BVR file has the correct date/time embedded in its name (in the format CAM.YYYYMMDD_HHMMSS.bvr). I can reproduce the problem by selecting "Trigger now" for the affected cameras.

Selecting "restart camera" fixes the problem temporarily - subsequent clips are shown in the clips list with the correct date/time/duration.

I checked all cameras before going to bed last night (selecting "Trigger now" on every camera to check that the resultant clip in the clips list had the right date/time/duration). But this morning, the clips list was showing incorrect times/durations for three of the cameras. The time offset is consistent for clips from a camera but inconsistent between the cameras (eg I have offsets of 4h27, 6h57, 13h44).

I've never seen this problem before. Of course it's a risk of using the very latest releases but I wanted to be able to try the substream option to get my CPU load down.

I have tried rebuilding, repairing the database and even recreating it from scratch.

I'll try running some of the cameras without the substream enabled and see if that provides any clues.

Setup: BI 5.2.7.12 , 10 x cameras (using substreams). Time on cameras and BI machine all correct via NTP.

Niel

 

[Gerwin]

Hello,
I can confirm niels detailed description of the Problem for my setup.
Restarting fixes temporarily, manual trigger reproduces the wrong timestamp. I also use substreams since available and turned the specific one off now for testing if the failure comes again with the hires stream.
Greetings! Gerwin.

 

[kklee]

I've had this problem pop up a couple of days ago on only one camera (out of 5, all using substreams) as well. Turning off the 'Use RTSP/stream timecode' setting in the camera config helped to isolate the problem to some sort of issue with the time encoding in the video stream. The camera itself showed the correct time, but any triggered video showed the incorrect time on the recording even though the time overlay (configured on the camera itself) showed the correct time. Rebooting the camera seems to have fixed the problem. I had just updated to 5.2.7.12 as well, so I'm not sure if that's related. I'm going to roll back to .11 anyways, since .12 seems to be randomly restarting.

 

[Gerwin]

Nice hint, thank you kklee, will try to turn off using RTSP/stream timecode.
Had no randomly restarts so far on 5.2.7.12
EDIT:

With "use RTSP/stream timecode" off, i have no wrong date & time, but wrong duration now, but also not at all clips as you can see...i´ll turn off all substreams for now and see what happens...

 

[Gerwin]

The only way for me to get rid off this problem is to not use substreams at all. tested for the whole night now, not one wrong timecode or duration.
I hope this will be fixed soon, because the substream function overall is a complete winner in my opinion.

 

[NielK]

I switched substreams off last night (on 9 of the cameras, left the 4k camera running a substream). This morning, all entries in the clips list look sensible.

 

[looney2ns]

The only way for me to get rid off this problem is to not use substreams at all. tested for the whole night now, not one wrong timecode or duration.
I hope this will be fixed soon, because the substream function overall is a complete winner in my opinion.

Be sure to email BI support.

 

[Gerwin]

Update on this:
Tried to resolve this for a few days now with BI Support (Ken), i think, he is still after it.
For me the temporary solution is to turn off hardware decoding on all cameras on my two installations, if i want to use substreams.
Now the timeline is correct, no 49 days clips any longer, no wrong dates and times.
I think, theres a problem if you use substreams AND hardware decoding at the same time. We´ll see ...

 

[Vini]

Update on this:
Tried to resolve this for a few days now with BI Support (Ken), i think, he is still after it.
For me the temporary solution is to turn off hardware decoding on all cameras on my two installations, if i want to use substreams.
Now the timeline is correct, no 49 days clips any longer, no wrong dates and times.
I think, theres a problem if you use substreams AND hardware decoding at the same time. We´ll see ...

Has this had any impact on your CPU usage?

 

[Gerwin]

Has this had any impact on your CPU usage?

Not really noticeable, a few percent cpu usage, I think less then 10%

 

[BrutusBoots]

Also experiencing this issue

 

[BrutusBoots]

Update on this:
Tried to resolve this for a few days now with BI Support (Ken), i think, he is still after it.
For me the temporary solution is to turn off hardware decoding on all cameras on my two installations, if i want to use substreams.
Now the timeline is correct, no 49 days clips any longer, no wrong dates and times.
I think, theres a problem if you use substreams AND hardware decoding at the same time. We´ll see ...

I don't use hardware decoding and I'm seeing the issue with substreams enabled fyi

 

[anijet]

Also experiencing this issue

Please email support so Ken knows how many of us have the problem.

 

[BrutusBoots]

Please email support so Ken knows how many of us have the problem.

Already done