I installed the latest available bleeding edge windows client but still find it lacking in some usability features as described below:
Please add an option to the devices list on the main screen to allow the list of cameras on each device to be collapsed and expanded in a similar way as was available in the version 2 client.
Please consider making the separator bar between the view list and the devices list movable so that it can be dragged up or down by the user to change how much of each list is displayed before scrolling is required.
Please add an option to allow defined external streams to be edited and also allow them to be deleted individually when more than one are defined. Currently one must delete all external streams if you wish to change or delete just one.
Please consider placing defined external streams into the devices list section and listing them individually under an “external streams” heading instead of lumping them all in together as a single view called “External Stream”.
Please allow individual external streams to be able to be dragged into any defined view.
There is an issue when refreshing server devices under the settings menu. When a server changes the displayed camera name of a device, the device name is not updated in the devices list of the bluecherry client. I found I had to remove the server from the client completely and re-add it before the device list would reflect the change in camera name.
Finally, there are currently at least 4 or 5 different ways in the client to display the RTSP stream information and usernames and passwords used to connect to servers and cameras. This is not a problem for small or home sites where a single user is responsible for setting up the server(s), maintaining the cameras and using the client. However, in a larger environment such as a business it is common for the servers and cameras to have restricted access and be maintained by an IT department, and the clients are often preconfigured for the relevant users with only the access they require. This is particularly relevant in the case of kiosk displays where the RSTP stream details should absolutely be restricted and hidden from users, and this should apply regardless of whether the kiosk or client device is linux, windows or a tablet.
Perhaps a password restricted checkbox in the client settings to enable or disable the display of RTSP stream information could be added. Alternately each bluecherry server already has a user configuration page with checkboxes for granting admin access, web access, remote access and archived video to various user accounts. The client application already uses this information to restrict access to event history. Why could it not also check the user’s admin status and only display the RTSP stream information and credentials when the user is listed as an admin of the bluecherry server? Note that the latter may not necessarily work for arbitrary external streams from random devices though.
Hey, @brett.gamlin! Thanks for your feedback. 1, 2, 3, 4, 5 and 6 are under consideration and shall enter development phase soon.
About 7, since we don’t require user authentication on the app, it is hard to decide who gets to access the server data. We could require Administrator Access. On Windows, MacOS and Mobile, we already require the device authentication (password or biometrics).
We don’t have access to those server configurations that grant access on the client. Another option is to require the server password to view the urls. What do you think?
Thank you for considering the points I raised for inclusion in your development program.
I am a little confused with your comment regarding point 7 though when you state that you already require device authentication such as biometrics for accessing server data. I must be missing something here as I don’t see that happening. I am running client version 3.0.0-beta19 on a windows 11 PC and have never once been prompted for any kind of authentication for viewing server data on the client.
Yes, I must know and enter the server’s username and password when first adding a new server to the client, but once a server is defined to the client, the username and password credentials used for connecting to the server are viewable at any time, by anyone without authentication, from the server and devices settings page simply by clicking the “show password” eyeball icon.
The username and passwords are also visible, without being prompted for authentication, when displaying the RTSP URL on individual cameras, and also when the “Show Server Name” overlay option is enabled in settings.
Also, the plaintext credentials can be found in the configuration file and the client log file.
All this information is very useful for administrators for debugging problems, but in a business environment access to credentials and passwords stored or displayed in plaintext are best hidden from general users.
Point 7 is a tough one though and if the application was not designed with credential security in mind then it is very hard to retrofit it later.
All I can suggest at present is to not use server admin credentials when adding servers to the client as doing so would allow anybody with access to the client to view those credentials and then potentially gain direct admin access to the servers as well.
I am a little confused with your comment regarding point 7 though when you state that you already require device authentication such as biometrics for accessing server data. I must be missing something here as I don’t see that happening. I am running client version 3.0.0-beta19 on a windows 11 PC and have never once been prompted for any kind of authentication for viewing server data on the client.
Apologies, there is a version issue here. The authentication requirement is under our bleeding edge release (the pre-release for the next version). See a video here. Under bleeding edge, the logs no longer register any credentials.
This is just the first part, we are planning to add the authentication request for everything in the app, including adding and editing a server. It is also on the plans to hide/encrypt the configuration file data from the user.
I can not tell you when this will be fixed or in what release this will land. We are planning on releasing client v3.0.0-beta20 this week, so it should be in the release after that.
Hi @bdlukaa, The changes to the view and device list look good and I believe that the other changes I had mentioned previously are still under consideration for a later release.
I have one more item for consideration:
In the client settings for servers and devices, there is a checkbox for listing offline devices in the devices list. This is fine, and they are indeed hidden when this checkbox is cleared. However the device count displayed in the devices list still shows the total number of devices including offline ones. Is this intentional, because it is confusing for the user and looks like a mistake.
