Experiences with the beta

Version 3 beta testing
1

After experimenting with Bluecherry Server 2.8.8 on real hardware and the 3.0.1 beta in a VM (documented elsewhere in this forum), I’ve installed v3.0.1 on a Z8350 mini PC with 2 GB memory running a minimal installation of Debian 10.4.0. This thread documents the issues seen so far.

On first startup of the server, /var/log/bluecherry.log records:

    Jul 21 19:25:57 z83 bc-server[14872]: I(): Auto-detected VAAPI device: /dev/dri/renderD128
    Jul 21 19:25:57 z83 bc-server[14872]: W(): VAAPI device /dev/dri/renderD128 does not exist or is not readable to bluecherry, hardware acceleration is not available

Looking at the device, I see:

crw-rw---- 1 root render 226, 128 Jul 21 19:16 /dev/dri/renderD128

So fix the problem with:

chown root:bluecherry /dev/dri/renderD128

and restart the server:

service bluecherry restart

This time, the log records:

Jul 21 19:39:18 z83 bc-server[17110]: I(): Initialized render node /dev/dri/renderD128 for VAAPI hardware acceleration

so that looks promising.

I added the first IP camera and the log recorded:

Jul 21 19:43:20 z83 bc-server[17110]: I(1/Front drive Sonoff 1): Setting up device
Jul 21 19:43:24 z83 bc-server[17110]: I(1/Front drive Sonoff 1): Stream started: Video: h264 (Main), yuv420p(progressive), 1920x1080, 1/90000(s) 1/20(c)
Jul 21 19:43:24 z83 bc-server[17110]: I(1/Front drive Sonoff 1): Switching to new recording schedule 'continuous'

Going into LIveView, video from the camera appeared for a few seconds, then froze. Nothing was recorded in the log. “Return to Admin panel” and back to LiveView resulted in the video appearing and running for several minutes before freezing again.
The log recorded:

Jul 21 19:51:40 z83 bc-server[17110]: W(1/Front drive Sonoff 1): Likely timestamping error. Ignoring.

Video remained frozen, so I tried Admin panel > LiveView > Admin panel > LiveView
several times but video failed to appear. Nothing in the log.

I restarted the Bluecherry server and LiveView started working again. This time, it continued working indefinitely.

Conclusions so far:

Minor bug with ownership of the renderD128 device.

LiveView works sometimes but not consistently, even with just one camera configured. Restarting the server seems to fix LiveView freezing or not appearing.

Everything else I’ve tried works perfectly.

2

Further observations about LiveView freezes:

Sometimes, video fails to appear when entering LiveView and an empty frame with zero wdth is shown. This is a hard failure: exiting from and entering LiveView repeatedly generates no video. The only way I’ve found to recover is to change something in the device properties, which forces the device to stop and restart. Or the more drastic “service bluecherry restart”.

Sometimes, a video image appears when LiveView is entered but immediately freezes. Recovery as above. It might be useful to have a button in the Web UI to force a stop and restart.

Sometimes, the live video runs for a while, freezes for several seconds, then resumes having jumped over the frozen time. For example, the timestamp superimposed on the video may stop at 20:20:15, the video freezes and resumes 10 seconds later with the timestamp showing 20:20:25.

The log records nothing when the effects described above are seen.

Sometimes, the live video runs for a while, then freezes and stays frozen indefinitely. In these cases, the log usually records:

Jul 21 20:50:28 z83 bc-server[18371]: E(1/<name of camera>): Read error from stream: End of file

Even though the log then records that the stream restarts, LiveView remains frozen until the device is stopped and restarted as above.

When LiveView fails to appear, freezes on entry or freezes indefinitely, the video stream continues to be recorded and can be played back successfuly.

3

You could also add the bluecherry user to the render group, then you dont need to be worried about that group losing access to VAAPI

4

Thanks. That would be a better solution.