ERROR "Database consistency check in progress"

System indicates that a Database Consistency Check is in progress.

In local:

Screen shows a white 3VR error message indicating that a database consistency check is in progress, and to contact technical support for more information. This message will sit in the middle of the shell screen. If the reporter is looking at a SpotMonitor TV screen, where the resolution is lower, only the top-left quarter or so of this screen will show.

The database recovering message shows:

For remote:

Remote users will get an error in the bottom of their sign in window, indicating that the database is recovering, and they won't be able to login.

  • This very rare issue happens when the 3VR detects a file corruption and attempts to repair it, to preserve your data and settings. On a normal DVR, a file corruption means you lose all the data that was on it. 3VR SmartRecorders attempt to repair file corruption automatically.

  • This error can be caused by power loss or abrupt hard resets of the unit.

  • Unfortunately, there is no way to know how far the DB recovery is in its process. Depending on when the issue was first reported, they should expect it to complete within 24 hours. When complete, the system will either reboot and begin to record normally, or it will change to show the "Server Failure" or the "Database Failure" error message.

  • If the self-repair is successful (it usually is), you get to keep your system with all its historical data and settings, although with a 24-hour gap ( usually the recovery process takes 12-24 hours), because it was not recording while trying to repair itself. The system will come back online automatically when a successful recover is completed. On rare occasions, the attempt to repair is unsuccessful, and the system must be RMA’d – this means there was a corruption that could not be fixed.

What must be done:

  • It is important to NOT REBOOT while the recovery is in progress--there are some automatic reboots the system will do during this process, but manually rebooting will cause it to take longer to recover.

  • Ask customer to check on the system in 24 hours, at which point it should be back up and recording normally or will have failed. In some cases it may also still be recovering after 24 hours--we treat these cases as failures. For systems pre-6.0.6 you can try updating the system to 6.0.6 through the administration console. The check will either finish successfully or fail and provide the option to reset the database. If the customer is in 6.0.6, reset the database. If the unit is an S-Series 1, see DB Reboot Failure Recovery for additional steps.

  • If the system comes back up after the recovery, we should get logs to find out what triggered the recovery.

If you are running older versions like 6.0.1.57140, consider upgrading to 7.2