DVR system locking up can't web in to manage


I have my Blue Cherry as a VM on ESXI 7.0. I am running Ubuntu 20.04.5 LTS. I do not know if it is a Ubuntu update or what that causes it to lock up. I am not able to log into the web management interface.
I reboot and still the same issue, can not web into the web management interface.
I do get the logon page and put in user name and password and then it just sits and thinks as it tries to log in. Then web page after a number of minutes comes up with Could not connect: [111] Connection refused. I did even check with the Linux client. When I find the system locked up the client also can not connect to the DVR server. I hope the uploaded photo works and is able to be seen.

I just tried the web management again and got the 504 gateway times. out. I checked the Linux client and it connects and shows active and appears to be recording. I am using continuous record on all cameras. But the Linux client is up and communicating, I can see the camera views. I will be setting a Cron job to reboot every 24 hours to help make sure the DVR is at least alive and recording. Not sure why the web management is not working. Just checked and UFW firewall is inactive so not being blocked that way.

Origional error message shown below.

I just ran apt-get update / upgrade and seen it was installing Bluecherry, noticed this message as it was installing.

Rebooted server Everything seems to be working and I can now log into the web management. But 2 weeks ago I was able to do that and then yesterday and today I was not able to do so after reboots. I will see if rc7 in a week or two have the same issues where I can not log into the web management.
I will check back and update this in a week or two. Next to get the reboot cron set. Running in continuous mode with like 18 cameras on a VM with 4 cores or CPUs I am running 35% CPU usage with 2265MB out of 16 Gig ram allocated. When the DVR is working, It works very, very well! Looking forward to when the stable DVR for Ubuntu 22.04 LTR is released.


Looks to be the same issue I’ve been having - I had the issue here as described - Error: Could not connect: [111 ] Connection refused. I applied the fix advised but didn’t seem to work - Kept locking up usually about every 1-2 days - I can only assume it was when the drive was getting full and perhaps removing old recordings etc.

It was stable for about 2 weeks then the bug came back. Ashame, it’s not possible to rollback MariaDB to see if that’s the issue… What version of MariaDB are you running?? My version is below.

As part of my troubleshooting I even re-built my NVR.

I’m running,

PRETTY_NAME=“Debian GNU/Linux 11 (bullseye)”
NAME=“Debian GNU/Linux”
VERSION=“11 (bullseye)”
SUPPORT_URL=“Debian -- User Support

16GB RAM / 11 Cameras / On Camera Motion Detection

MariaDB --version - mariadb Ver 15.1 Distrib 10.5.18-MariaDB, for debian-linux-gnu (x86_64)

RC7 has been released for Ubuntu 20.04 and 22.04 which should resolve this. Bullseye RC7 should be out this week for testing.


Well its been a week since I posted my information. I am running DVR Version 3.1.0-rc7. I also did add a cron job to reboot the entire server every night. So I assume that is also maybe helping. Though not really sure, because before applying updates & rc7 and everything to the Ubuntu server (Linux and Bluecherry updates.) a reboot would not fix the issue. As Curtis noted, I assume the rc7 it working well and my nightly reboot is moot point, but I am leaving it in. My System is running on ESXI 7.0.3 I think patch J or something. So will keep an eye on things. Before this post I thought I was running the rc7. Thank you Curtis for the update info.

Cool Ubuntu 22.04 be out soon. I will plan to update to that, build a new VM fully configured for that and then can make my OVF file for backup with everything configured and ready to go. Had to entirely rebuild and add additional capacity to the ESXI server last month and lucky I had OVF files of my critical VM machines and made doing a restore of the entire VM an easy quick process.