Blue Iris Updates - Official Thread 6.0.7.2

[MikeLud1]

I updated to v6.0.7.2 and lost all my camera groups. Does anyone know how to get back the groups. I did downgrade to v6.0.7.1 and the camera groups are still missing

 

[rkn]

I updated to v6.0.7.2 and lost all my camera groups. Does anyone know how to get back the groups. I did downgrade to v6.0.7.1 and the camera groups are still missing

Based on the BI change log file's comment it appears issues aren't unexpected:

An issue likely introduced in 6.0.5.4 where adding more than 256 cameras (possibleby deleting/importing/etc.) could cause group associations to become corrupted.This version does a re-mapping based on the “groups” list string in camerasettings—please check your group camera memberships following this update to insure they are accurate.

This makes me think a full or partial configuration restore from backup looks the only option if available. I've got enough AI object tracking issues with 6.0.7.x on my test system (ignores too many confirmed AI detections compared to 6.0.5.x) so held off 6.0.7.2 given the comment above looks concerning.

 

[IAmATeaf]

I updated to v6.0.7.2 and lost all my camera groups. Does anyone know how to get back the groups. I did downgrade to v6.0.7.1 and the camera groups are still missing

Might be worth checking in the Registry if the 'Groups' branch is still there ?

 

[MikeLud1]

Might be worth checking in the Registry if the 'Groups' branch is still there ?

I did and they are gone

 

[jaydeel]

As I've previously posted, I routinely track registry changes across BI updates using NirSoft RegistryChangesView and thought I'd share a few observations regarding the group-related changes introduced in 6.0.5.4.

When 6.0.5.4 was released, I noticed a new DWORD value named Number added under every Group registry key. Subsequent releases (6.0.5.5, 6.0.5.6, etc.) continued to change these values, which initially made me suspect BI was introducing some sort of internal group identifier.


The 6.0.7.2 changelog eventually provided an important clue:

An issue likely introduced in 6.0.5.4 where adding more than 256 cameras (possible by deleting/importing/etc.) could cause group associations to become corrupted.

After updating to 6.0.7.2, I noticed a new 128-byte REG_BINARY value named cameras128 added under most Group registry keys.


At first I assumed this was replacing the older group membership mechanism. However, after further investigation I discovered that each Group key actually contains two membership bitmaps:

• cameras (32 bytes)
• cameras128 (128 bytes)

The contents of the first 32 bytes of cameras128 match the existing cameras bitmap exactly.

This appears significant because:

• 32 bytes = 256 bits
• 128 bytes = 1024 bits

which aligns almost perfectly with the 256-camera limitation described in the 6.0.7.2 changelog.

By comparing these bitmaps against the JSON camlist output, it appears that group membership is represented as a bitmap indexed by the camera number values returned by the Blue Iris webserver API (identical to regkey Number mentioned above).

I also found evidence that Blue Iris currently maintains multiple representations of group membership:

Per-camera:
group  (REG_SZ)
groups (REG_SZ)

Per-group:
cameras (REG_BINARY, 32-byte bitmap)
cameras128 (REG_BINARY, 128-byte bitmap)

Per-camera examples from my system:

DriveWay-1:
group = Outdoor;Garage;Front;DW1cloneset;Driveway
groups = Outdoor;Garage;Front;DW1cloneset;Driveway

DriveWay-2:
group = Outdoor;Front;Driveway
groups = Outdoor;Front;Entry;Driveway

Interestingly, those two values are not always identical.

I also discovered that some cameras have neither regkey present.

The 6.0.7.2 changelog specifically states that the repair process rebuilt associations using the groups list string in camera settings. That wording now appears very deliberate.

Unfortunately, the 6.0.7.2 remapping was not completely accurate on my system. Several manually-created groups disappeared entirely, and some existing groups lost members.

One possible explanation is that some cameras either lacked a groups value entirely or contained group metadata that differed from the current bitmap representation. If the repair process relied exclusively on the groups string, those memberships may not have been recoverable.

The good news is that I was able to recover everything using pre-update registry backups and JSON camlist exports.

I also compared JSON camlist exports before and after updating from 6.0.7.2 to 6.0.7.3. The group-to-camera mappings were identical, suggesting that whatever repair work was done in 6.0.7.2 appears stable in 6.0.7.3.

My current best guess regarding the architecture is:

Camera
 ├─ group      (legacy)
 ├─ groups     (authoritative string list)
 └─ Number

Group
 ├─ Number
 ├─ cameras      (256-bit bitmap)
 └─ cameras128   (1024-bit bitmap)
 
and 6.0.7.2 probably did:
 groups string
     ↓
rebuild cameras/cameras128

rather than:
group string
     ↓
rebuild cameras/cameras128

with 6.0.7.2 rebuilding the group bitmaps from the per-camera groups strings.

If others have systems with large camera counts or have observed missing groups after 6.0.7.2, I'd be interested in comparing notes.

One lesson learned: before major BI updates, I now save:

1. Blue Iris registry backup
2. JSON camlist output
3. CSV export of group names, camera names, and camera numbers
4. Registry export of HKLM\SOFTWARE\Perspective Software\Blue Iris\Groups

Those backups should make it possible to identify and reconstruct every group change that occurs during the current 6.0.7 and future migrations.