Reolink Desktop Client drops streams in continuous recording mode?

[BCLoco_670093297197135]

I'm not sure exactly how to word this problem, and that definitely increases the chances I've missed a previous thread covering this issue. Please share a link if that's the case.

I have 8 cameras currently connected to my NVR, and running in continuous recording at each camera's highest bitrate. Cameras are RLC-810A (3x), Duo 2 (4x), and one RLC-823A. The total throughput can be seen in the screenshot. I have the video file duration set to 5 minutes, and hardware decoding first.

What happens is random camera streams will stop generating video files. It's like the camera(s) goes offline, except that it hasn't. I can always access any camera through the browser, or through the Android app. It even (usually) still shows the blue dot and "Connected" next to it's name in the desktop client. Closing the desktop client and immediately reopening it always resolves the issue. Sometimes the issue won't reappear for 8 hours, sometimes longer. And in that timeframe, sometimes it affects just 1 or 2 streams, sometimes almost all of them. There appears to be no pattern to which stream(s) will drop out. If I leave the client running continuously for long enough (36 hours or more?) without restarting it, all cameras will eventually stop generating video files.

I'm confident this is not an issue with the cameras or network. Something is wrong with either the desktop client or the NVR, since restarting the client will resolve the issue for a time. I started with v8.8.5 and the issue was present. No change with 8.10.2, and I just installed 8.10.4, but I doubt I will see a difference.



My NVR is an old server (HP Proliant ML110 G7 running Windows Server 2022 v21H2 build 20348.1726 (currently it's an evaluation version of Windows). See screenshot for relevant hardware specs.

[BCLoco_670093297197135]

Update: Immediately after my last post, I decided to try changing the 'Hardware Decoding First' setting to OFF. That change, or the upgrade to 8.10.4, resulted in the longest run to date with no dropped streams. The first dropped stream occurred roughly 40 hours in, and a second stream dropped around the 44 hour mark. That is a significant change.

Upon closing and restarting the desktop client, the 'Hardware Decoding First' parameter reset to ON. I have left it that way to see if the improvement came from the setting change, or the client update.

[joseph_1979]

@bcloco_670093297197135 I presume the cams are connected via a switch to your server on which you are running the Windows client. When this happens go to the task manager and on performance tab check the receive bytes on the connected eth. If it is low then the camera are not sending the stream but I doubt this is the case.

As a test I would remove the recording and have the live view and see whether this occurs. I suggest you to start with low resolution and then repeat the test with the highest resolution. Leave hw acceleration off (you can permanently set it to FALSE in the usersettings file). Repeat the tests with recording on. I would also use an application to pink the cameras to ensure they are always reachable. There are myriads of such programs.