Geovision Database Problems

[Mattb 0]

We have several Geovision 1120 and 1480 version 8.3 systems with two to five dedicated video storage drives that are not reliably recycling older video. Sometimes there be a few of the date folders containing a couple of random video files for a few different cameras. As an example, a 16-camera system may have deleted (recycled) all of June, except for camera-12 folder 0611 containing eight video segments and camera-10 folder 0619 containing four video segments. The video in these ‘orphan’ folders is not indexed in the Viewlog.

 

Compounding the problem, when reviewing video in a previous month with the Viewlog, some cameras are not available in the Viewlog, and come up with blue panels. Again, the ‘missing’ camera playbacks are random with different recorders. The video is really on the disk, just not in the database. The video will usually be from the same cameras that had orphaned date folders.

 

The oldest recorders were first deployed in 2006; there has been occasional database issues, but since the 8.3 upgrades/fresh installs the database problems have become routine on recorders with over two dedicated storage drives.

 

For now, my solution has been to run a utility to delete the empty folders, and then run the database repair utility full rebuild. Performing a complete ‘rebuild all information’ will usually correct the problems – the video segments in the oldest, orphan date folders is recycled appropriately, in the but a month or two later the same problems occur. The faster database repair will often skip a camera or three in previous month’s recording (never in the current month.) With a dozen recorders, some containing 5 or so terabytes of video spanning a few months, this becomes time consuming. The issue is uncommon on a recorder that has just two or three dedicated video drives.

 

Everything records round-the-clock, recycle is on, and the hardware is typical, the software is XP & Geo 8.3, some computers are ‘fresh installs’ and some upgrade installs. There is a dedicated O/S drive that holds the Geovision database. Every recorder is rebooted and check-disked every two or three weeks.

 

All computers are set up with one storage container, with a path pointing to a uniquely named storage folder on each dedicated video storage disk.

 

I have even tried deleting the database folder contents to no avail.

 

Should each disk drive be set up as a storage container, with one path to the storage folder?

 

Any suggestions would be appreciated.

[rory 0]

How is the PC setup? Is it a default XP install, or tweaked?

[cctv_down_under 0]

This corruption is common - and is why the database recovery tool was made -

 

I doubt your running your system on a UPS that shuts down the DVR - this is CRITICAL - the video is first stored in memory before a closed file is created and if not shut down correcty it dumps this invomplete file onto the HDD - hence a corrupted video.

 

The issue then becomes that the file index says - ok write to HDD, but HDD syas "cant write there" ..so OS syas..ok then write to next block and HDD says "cant write there" oever and over again until it has skipped that part of the HDD.

 

Its not really an issue of a bad sector - more an area that the software can not recognise the size of the incomplete file.....for example sometimes when you download a bit torrent you get parts of a file, but until the file is complete it cant be played.

 

The fix is simple - you will usually see that ONLY 1 x file is in each corrupt folder - so go to cam1 folder then open it - then change your view to "thumbnail view" - at this point you should know which folders are corrupt anyhow becasue they will be massively out fo file sequence ie all folders will be named as dates and some will be out of sequence - a long time ago - by switching to thumbnail view you are getting an auto preview of what is in the folder - however if the file in the folder is not able to be auto previewed then it is normally corrupted and you can simply remove these folders and runt he database repair tool.

 

To avoid this buy a UPS that has the ability to shutdown windows and the Geo program - TBH you only need a basic script to stop geo then most UPS mobs have the ability to shut down any windows box.

 

This will stop the ram dumping files to your HDD that are corrupted.

 

 

Hope this helps

 

Aussie Lad!

[Mattb 0]

The problem is actually files not indexed in the database, but actually on the hard drive. The integrity of the video files is excellent. Line power quality is not an issue in this environment.

 

Video files don’t show up in the Viewlog, but are on the disk – If the Viewlog is in a 16-panel mode, the “missing” video is in a blue panel or several blue panels. After the database repair utility is run, the “missing” video becomes available.

 

The “missing” video files become “orphaned”, and do not recycle – the initial post describes the problem in detail.

 

The computers are re-booted and chkdsk’ed every 3-4 weeks. All video is recorded 24x7 in 5-minute segments using the motion detection for ‘economic round-the-clock’ recording. Naturally, all the DVRs are have only Windows, GeoVision, and the DVD writing software – Nero or Roxio

 

The dedicated video storage disks are configured as one storage group, with a path pointing to a uniquely named storage folder on each dedicated video storage disk. Storage Group 1 will contain Drive-D/path-1, then Drive-E/path-2 etc for up to five drives.

 

I have considered creating a storage group for each drive, but I don’t think that is the intention of GeoVision. My understanding is that a storage group would be all local drives, a second NAS, a third storage group a removable USB drive etc.

 

When I performed an upgrade when the software automatically put all the drives in one storage group.

----Version 8.2.0.0 - Released date: 02/22/2008 features

----Up to 8 storage groups with different storage locations can be created.

 

Any suggestion would be appreciated – Still no response from the USA GeoVision distributor Usavisionsys, although they have been really helpful in the past, even to the point of providing patches ahead of releases.