Hello @brett.gamlin!
Please download the client from our latest bleeding edge.
This issue was fixed here
Hi
I downloaded the lastest bleeding edge windows client.
I uninstalled the previous client from my PC, deleted the com.bluecherry folder from the Appdata\Roaming folder in my profile, and then installed the bleeding edge version and reconfigured it from scratch.
Although it initially looked like the problem still existed, as the display still went unresponsive during the loading of the cameras for a minute or so, it did come good and is now behaving normally.
One minor point comes to mind though - would it be possible to include a build number or build date in the version information string displayed in the “Updates, Help and Privacy” tab of the client? Currently it is not possible to distinguish which version is installed on a PC as the version information displayed for the actual 3.0.0-beta22 version is the same as the version information displayed for the 3.0.0-beta22 bleeding edge version.
Cheers.
1 Like
Looks like I was a bit too quick with the previous reply. I dont think the problem is entirely resolved yet.
The bleeding edge client is still hanging intermittently, such as when changing the layout mode for example between multiple and compact or vice versa, but this is not happening everytime.
When it does however, it still needs to be killed by task manager, but then seems to work again after a restart of the client application.
Yes, we are working on that. Add build number · Issue #330
The hang is directly related to your hardware. In my machine, I can load up to 12 cameras without having any issues (AMD RYZEN 5, 20GB RAM, Integrated GPU). How many cameras are you displaying?
Can you try opening the client with the --mdk flag?
I was able to achieve a much better performance with MDK, with no crashes. With the default renderer (mpv), the app crashed with the same amount of cameras after a minute. MDK is already the default renderer for MacOS and Linux. We are investigating the possibility of making it the default renderer for Windows as well. Your feedback is really important.
I am testing the V3 client against several of my bluecherry servers. For this test I am opening 17 cameras from one of those servers. Most of our 10 or servers have around 16 cameras each.
I doubt it is the hardware. I am testing this on a PC with an intel i9 (24 cores) processor, 32GB RAM and NVIDIA T400 graphics adapter.
The --mdk option does appear to have resolved the hanging issue, but it is having problems rendering video from two older cameras.
Without the --mdk option, the bluecherry client will display all cameras but will hang when you first add all the cameras to the view. However, after killing the client with task manager, the client will restart and display all cameras normally without hanging again (unless you try to change view settings too much and then it hangs). The following two screen dumps show the hung view, and then the same view after the client is killed and restarted.
With the --mdk option, the bluecherry client has not hung on me at all yet. However it is failing to display video from two older analogue cameras which are connected though AXIS P7304 video encoders. They get displayed, first as LATE and then as TIMED OUT. The following screen dump shows the two timeouts on the two older cameras.
It is good to hear that the issue is no longer present when using MDK. We will work on making it the default video backend.
Regarding the two older cameras, to help us identify any errors or issues with the video streams, could you please send us the log files from their streams? You can find those in the log folder (Settings > Advanced Settings). Specifically, please send the files pertaining to the cameras experiencing the issue. If those logs are not sufficient, we may need access to your server to verify the issue directly.
When starting with the --mdk parameter, the client does not create the “logs” directory and does not create any individual camera log files.
When starting without the --mdk parameter, the client does create the logs directory and does create the individual camera logs.
I have attached the cameras logs from the system started without the --mdk parameter (which is the system that is displaying all cameras correctly):
Warehouse 3 Rear (mqn-vms-06.bundysugar.com.au).txt (6.8 KB)
WH 11 Inside Right (mqn-vms-06.bundysugar.com.au).txt (7.2 KB)