Server 3.1.7 occasionally stops processing video from some cameras

Server discussion
1

I have noticed that occasionally by BC server 3.1.7 will stop recording the video from a camera. Other cameras on the same server continue to be recorded normally. The video that has stalled never recovers by itself and requires the bluecherry service to be restarted before it will start recording the video normally again.

The bluecherry.log file starts logging repeating messages for the affected camera like the following:

2024-11-18T12:29:02.871845+10:00 debian12-bluecherry bc-server[141179]: I(4/aid9701): Setting up device
2024-11-18T12:29:07.940092+10:00 debian12-bluecherry bc-server[141179]: I(4/aid9701): Stream started: h264, 1/90000(s) 1/90000(c); aac
2024-11-18T12:29:07.940308+10:00 debian12-bluecherry bc-server[141179]: I(4/aid9701): Switching to new recording schedule ‘continuous’
2024-11-18T12:29:07.974048+10:00 debian12-bluecherry bc-server[141179]: I(4/aid9701): Got bad dts=NOPTS on stream 0, passing to libavformat to handle
2024-11-18T12:29:13.451187+10:00 debian12-bluecherry bc-server[141179]: I(4/aid9701): Making a snapshot
2024-11-18T12:29:13.527897+10:00 debian12-bluecherry bc-server[141179]: I(4/aid9701): Saved snapshot from single keyframe
2024-11-18T12:32:38.366359+10:00 debian12-bluecherry bc-server[141179]: W(4/aid9701): Likely timestamping error. Ignoring.
2024-11-18T12:32:38.367985+10:00 debian12-bluecherry bc-server[141179]: W(4/aid9701): Likely timestamping(19352340) error. Ignoring.
2024-11-18T12:32:38.372411+10:00 debian12-bluecherry bc-server[141179]: I(4/aid9701): Got bad dts=19352340 while last was 19352430 on stream 0, setting to last+1
2024-11-18T12:32:38.372573+10:00 debian12-bluecherry bc-server[141179]: E(4/aid9701): Error writing frame to recording: Invalid argument
2024-11-18T12:32:38.372746+10:00 debian12-bluecherry bc-server[141179]: E(4/aid9701): Error writing frame to recording. Likely timestamping problem. Ignoring.

The corresponding BC server web client live view will show a image of what looks like perhaps the last successful image before the problem started, but the image never changes. I have attached a sample screen shot of the web client display when one of the recording is in this “stalled” state.

Live View
Live View755×428 122 KB

The windows v3 client will show a blank image where the recording should be with just a continuous loading message, and will not restart the video stream until after the server’s bluecherry service is restarted and the camera is closed and re-opened on the client.

The camera itself is working fine throughout the entire process as VLC and other tools show that the RTSP stream is working fine.

Can you offer any suggestions on how to debug this issue further and perhaps determine what might be triggering it in the first place.

1 Like
2

i have the same issue on two servers. it happens to me when one of the cameras goes down. upon coming back up bluecherry won’t properly connect with them again until the service is rebooted.

3

We believe we have identified the problem, we are working on resolving this.

4

Was this resolved as we are having a completely identical issue with version 3.1.7.

We were unable to roll-back to a previous version, but noticed checking for update a version 3.1.8 is available and got pushed down. Checking if that was a resolution.

5

Please try 3.1.8, we are working on releases notes but it should resolve the issue.

6

Did not fix the issue, in approximately a 24-hour period the cameras stop again.