Bug: Layout issues in 2.2.9

[curtishall]

Reported from two different customers:

I have recently downloaded and installed the new 2.2.9 client for Windows 64 and whilst it has some good additional features, it has one very annoying problem and one less annoying issue.

1. The primary problem occurs when switching between layouts of different sizes or layouts containing differing number of cameras which is causing cameras from one layout to pop up on the other layout when there is a vacant spot.

For example I have a layout called "Bingera" (See attachment 1-BIN.JPG) which contains 3 cameras on a 2x2 layout format. One square in empty.

I then move to a different layout called "Packaging" (See attachment 2-PACK.jpg) which contains 9 cameras on a 3x3 layour format. All good so far.

However, when I return the "Bingera" layout, the fourth square which should be empty is now filled with a camera from the previous layout (See attachment 3-BIN.jpg).

This is occurring consistently and repeatedly on all of my client installations that are running 2.2.9 when switching between layouts and is a real problem for users who need to monitor multiple cameras across several layouts. My clients machines are all running windows 10.

2. The second less annoying problem occurs when defining a new layout. When I drag cameras from the server camera list on the left hand side and try to place then in a particular position on the new layout (eg. "Bush Paddock"), the cameras always drops the bottom most, left most vacant position on the layout regardless of where I was trying to place it (see attachment 4-BUSH.jpg) which then requires me to have to reposition the camera a second time.

These issues did not occur in 2.2.6.

Is there an updated version of the client available which resolves these issues.

[curtishall]

https://bluecherry.freshdesk.com/a/tickets/22728

https://bluecherry.freshdesk.com/a/tickets/22725

[pyeager56]

I am experiencing this same issue. Any idea when it might be addressed?

[curtishall]

We are actually working on rewriting the client which will resolve this. If the new client is delayed longer then expected I'll see about getting this problem fixed in the current client.