Initial impressions and issues

1

I’ve been playing with Bluecherry for a few days and have a few observations and issues. None of them are show-stoppers but I thought I’d list them in case they’re of interest to the developers and in case there are simple solutions.

My requirement is a for a continously-recording system for several IP cameras and Bluecherry is by far the best software I’ve tried. Generally, it’s very impressive.

My system:

Debian 9.12.0 with Bluecherry Server 2.8.8 on a Z83 Mini PC with 2 GB RAM, 32 GB MMC storage, 2 TB USB disk to store recordings and 100 Mb Ethernet.

The Server has four 1920 x 1080 WiFi IP cameras configured, all recording continuously, no motion detection.

Although the hardware is low-powered, Bluecherry Server typically reports 21% CPU usage and 29% memory usage when continuously recording 4 cameras.

Clients:
Firefox 78.0.2 and Chrome 84.0.4147.8 browsers on a Windows 10 PC, Gb Ethernet.
Bluecherry Client 2.2.6, also on the Windows PC.
IPCam Viewer Basic (v7.0.7) on an Android 10 WiFi-connected mobile phone.

Issues:

  1. On Firefox, clicking on “System Log” in the menu list on the left of the screen does nothing (all the other menu items work). Pasting https://:7001/log into the Firefox address bar successfully displays the log. On Chrome, clicking on “System Log” in the menu works, so this is a Firefox-related issue.

  2. On entering the Playback screen, the “Motion” box is always ticked. This is a minor nuisance for a user interested only in continuous recordings. It would be good if this box retained its setting from the last time Playback was entered.

  3. “Live View” is temperamental. I suspect that each of the following issues has a common cause, possibly a resource contraint on my server (although note the low-ish CPU and memory usage above). They have all been observed on both Firefox and Chrome.

3.1 Sometimes the realtime video from four cameras displays perfectly; sometimes, the video disappears every few seconds, then re-appears.

3.2 The videos show an increasing lag, sometimes freezing for several seconds, then jumping forward in time but never catching up. Each video source has a realtime timestamp superimposed and this typically advances by only 40 seconds every minute. This also happens, although not consistently, in the Bluecherry client.

3.3 With Firefox and Chrome, after a variable interval (several minutes), all video streams freeze and never recover. This doesn’t happen in the Bluecherry client, which continues displaying video indefinitely, although sometimes with increasing lag as noted above.

3.4 Sometimes a video stream disappears in both Firefox and Chrome, being replaced with an “End of file” error, followed by “Not found”, then re-appears a few seconds later.

In general, the Bluecherry client is much more reliable at displaying Live View video than the browsers.

These issues apply only to “Live View”. Recordings are perfect and that’s my main requirement. Live View would be a nice extra if I can make it work properly.

In summary, although that seems like a long list of issues, the software fully meets my need for a system that records IP cameras continuously. The Web UI is intuitive and easy to use and Playback is especially well implemented. I like the software!

2

A further issue:

Sometimes,when I switch to Live View in a browser, some of the video streams fail to appear. A way to make them work again is to change something in the IP camera properties (for example the RTSP port), save the changes, change it back, save again and go back to Live View. Then the video stream appears! Any idea why doing this makes it work again?

3

I would be curious which issues still remain in the latest beta version of v3. Are you willing to try that?

4

Thanks for the reply. I’ve tried the latest beta in a Debian 10 VM with 4 GB of memory but, sadly, Live View doesn’t work at all for me with this version of the software. I can “click to select a camera” and choose one, but nothing happens - the video streams never appear. Ticking or unticking “Use substream for live view” has no effect on the failure.

The log records lines like:

Jul 20 17:30:11 debian10-cctv-vm bc-server[483]: I(3/Garden Tapo 1): Substream started: Video: h264 (High), yuvj420p(pc, bt709, progressive), 640x360, 1/90000(s) 1/30(c)
Jul 20 17:31:11 debian10-cctv-vm bc-server[483]: I(2/Study Sonoff 2): Substream started: Video: h264 (Main), yuv420p(progressive), 640x360, 1/90000(s) 1/20(c)
Jul 20 17:32:37 debian10-cctv-vm bc-server[483]: E(2/Study Sonoff 2): Read error from liveview substream: End of file
Jul 20 17:35:12 debian10-cctv-vm bc-server[483]: E(3/Garden Tapo 1): Read error from liveview substream: End of file

Despite this, the software records the streams and plays them back perfectly. It just won’t display them live!

The other issue, “Clicking System Log having no effect in Firefox” is still there.

I’m very happy to experiment, provide logs, etc, if it will help.

5

Can you send me a message with remote login details to that computer (SSH)? If you can port 7001 that would also be great.

6

Sure. It’ll take me 10 minutes or so to configure the firewall - I’ll DM when set up. I’ve just disovered that changing VAAPI device to “None” in General Settings results in the video streams appearing (sometimes but not consistently) in Live View. Leaving this at the default /dev/dri/renderD128 or setting it to Autodetect results in nothing appearing in Live View. A further oddity: although four IP cameras are configured, only three of them are listed in Playback and appear in Live View.

7

Also have same issue re log, I was able to determine that this is a uBlock Origin issue, as there is a filter for “/log?type=” in the EasyPrivacy list, and the GET request in the browser for the log is “https://server:7001/log?type=ajax_content”

Once I finally got the docker instance to work (still not sure how I did that) I am also not able to use the VAAPI decoding as it results in liveview being blank and 0 pixels wide per camera.

I have a Haswell xeon on Ubuntu 18.04.3, with the edge (20.04) kernel 5.4.0-39 x86-64, I assume that the integrated video is supported using the i915 driver, at least for H264 streams.
From inside the docker container it seems to show VAAPI working:

vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: Intel i965 driver for Intel® Haswell Server - 2.1.0
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264MultiviewHigh : VAEntrypointVLD
VAProfileH264MultiviewHigh : VAEntrypointEncSlice
VAProfileH264StereoHigh : VAEntrypointVLD
VAProfileH264StereoHigh : VAEntrypointEncSlice
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
VAProfileJPEGBaseline : VAEntrypointVLD

8

Thanks for the tip about uBlock Origin. That was indeed the cause of the “Clicking System Log having no effect” issue.

I also had an issue with one of my four cameras not appearing in the Playback list. After deleting it and adding it again with exactly the same details, it now appears in the list. Weird!

Just to wrap up this thread, the 3.0.1 beta software is now working better for me than 2.8.8, the critical setting being “VAAPI device: None”. If either “Autodetect” or “/dev/dri/RenderD128” is selected, LiveView doesn’t work at all in my VM. With it set to “None”, LiveView works but not consistently. I’ll rebuild my hardware to use the beta server to rule out VM peculiarities, do some experimentation to try and narrow down when LiveView fails and I’ll then post further in the beta section of the forum.