CPU from 67% to 82%+ After Update to 5.3.7.11 (same was true after update to 5.3.7.5)

[Mike Newman]

Prior to update versions 5.3.7.5 and 5.3.7.11,the web UI was indicating around 67%. After these two updates it now fluctuates between a minimum of 82% to 100%. I have made no other changes to anything other than install the updates.

My current environment is:

BlueIris 5 (now at v5.3.7.11) running on a Dell OptiPlex i9-9900 @ 3.10GHz with 32GB RAM running Windows 10 x64 OS that is fully current with updates and Kaspersky AV (Kaspersky AV set to exclude scanning the BlueIris Directories)

• 28 IP Cameras (see breakdown below with FPS, Resolution and HW acceleration details for each):
  • 22 Hikvision DS-2CD2385FWD-I IP Camera set at 1920x1080 @ Max (frame) rate at 15fps both on BlueIris and on Camera config, using Intel HW Acceleration
  • 2x Jidetecch - P2-20X-5MPF PTZ IPCameras set at 1920x1080 @ Max (frame) rate at 15fps both BlueIris and on Camera config, using Intel HW Acceleration
  • 1x Montavue (OEM is Dahua) MTT5102-AIAD IP Camera set at 1920x1080 @ Max (frame) rate at 15fps both BlueIris and on Camera config, using Intel HW Acceleration
  • 2x Doorbird D2101KV-4A Entry Systems (ONVIF compatible) set at 720p @ Max (frame) rate at 10fps both BlueIris and on Camera config, no HW Acceleration
  • 1x Doorbird D2101V Entry Systems (ONVIF compatible) set at 720p @ Max (frame) rate at 10fps both BlueIris and on Camera config, no HW Acceleration
• Only recording on motion
• Default HW Acceleration set to Intel

1. Is anyone else having this issue?
2. If yes, what did you do to solve the issue to get performance back to where it was prior to these updates?

Need your help. Thanks!

Mike

 

[sebastiantombs]

If you want a real performance increase use the sub stream function that is now in BI. If you do that I'd guess your CPU utilization will drop to under 20%. I have 15 cameras running on an i7-6700K. The cameras are a mix of 13 2MP and 2 4MP. CPU sits around 7%. Oh yeah, check and make sure you're recording direct to disk, another big saver of CPU cycles.

If you do go to sub streams, use the lowest resolution you can. You will need to reconfigure motion detection zones because of the change in resolution.

BI uses the sub streams for motion detection and display of multiple cameras on the console and in UI3. If you single view a camera the main stream is used and the main stream is also used for playback. Both streams are recorded by default and the sub stream recording can be shut off if you like. The sub stream recording doesn't really impact disk space very much, at all, due to the lower resolution.

 

[Mike Newman]

Thank you Sebastiatombs. But that's not the key issue for me - I want to understand what happened between updates that caused the CPU to go from an acceptable 68% or so to an unacceptable range of the 82%-100% with average showing around 93% when I made no other changes.

 

[sebastiantombs]

Have you tried a reboot? I've been using sub streams since the feature was added and haven't seen any increase and, in fact, a slight decrease in CPU with each revision. It has stabilized over the last few versions. My hardware acceleration is Nvidia based and I have seen recent complaints that there are memory leaks with Intel recently for a few people but that doesn't explain your problem.

Do you have anything else running on that machine?

 

[Mike Newman]

Nothing else running other than Kaspersky AV. It is dedicated to BI5. There are no VMs. It is a clean Win10x64 all running on the hardware (not as a vm) and BI5 is installed on that. I have a 10G Intel NIC attached to a 10G port on a Dell POE+ switch. All the camera's are attached via 1Gbps ports on that Dell POE+ switch. So they all have a dedicated 1Gbps connection each. I'm using nowhere near the bandwidth or throughput of any of those ports or the switch in its entirety.

 

[Mike Newman]

Again, nothing has changed on this machine at all.

 

[sebastiantombs]

I'd still say to switch to sub streams and don't worry about the CPU without them. I haven't seen any other problems like this commented on so I'm out of things to try.

One other comment about sub streams. I saw someone mention some distortion/tearing using record on motion only while using sub streams. Apparently, it is limited to that scenario only and doesn't happen with 24/7 recording. The user who posted has contacted BI support regarding it and is waiting for an response or, better yet, cure.

 

[ajwitt]

Try doing a find/inspect of each camera as some have reported that fixing issues. It doesn't lose any of your settings - you are not deleting and adding the camera back - simply going into each camera setting and redoing the find/inspect.

Also check that since you are say you not using substreams (although I highly recommend you do), that the recent updates now are pulling the substream automatically and are pulling substream2 and for a lot of cameras, the substream2 is a higher quality than substream1, so if it is pulling another 2MP on several cameras, that would be be the culprit. And then make sure that the substream is the same FPS/framerate and compression. You may be running H264 on the mainstream and H265 on the substream for example and that may contribute to the increased load, along with pulling another 2MP quality stream.

Change the substream to #1 and run as low quality as you find acceptable. With that many cameras showing on a screen at once, you could run a D1stream and bitrate of 256 and not notice a difference in quality.

 

[Mike Newman]

Thanks AJwitt. Problem Solved. Here's what I found and the solution.

My Investigate and The Cause to Spiking CPU after Upgrade:

Upon going in to each cams "Camera Settings" on the "Video" tab, the drop down for the "Hardware decode" field had changed from the pick of "Default" to "None" on over 1/2 of the cameras. This change occurred mysteriously and without any user input by me, after the last version update 5.3.7.11 (and most likely after the one right before that of 5.3.7.5). My "Default" setting in the Blue Iris Settings for "HW accelerated decode (restart cameras):" field is "Intel" so all of the cameras set at "Default" for the "Hardware decode" field were using Intel HW accelerated decode. Thus, the fact that the upgrade to 5.3.7.5 and 5.3.7.11 changed 1/2 of the cameras to "None" in their settings in the "HW accelerated decode" field stopped them from benefiting from the default Intel HW accelerated decode. That explains why there was a spike in CPU usage within Blue Iris after the upgrade. So that's what the root cause was to this issue of spiked CPU after the upgrade.

The Solution:

The solution was to change all of the camera's which had the setting of "None" in the "HW decode" field to "Default." By doing so, the Default setting was Intel HW accelerated decode for all the cameras. Then I also followed up by clicking on the "Configure" button under the "Video" tab for each camera and picking the "Find/inspect..." button to allow Blue Iris to perform an interrogation of each camera and thereafter automatically set the settings on that configuration screen. After doing so this on each camera, I then clicked on the "OK" button on that dialog box, and then clicked the "OK" button on the Video tab configuration screen. This then restarted the camera, and voila, dropping CPU utilization after each restart. did this one by one for every camera except I didn't do the "Find/inspect...." for the Doorbirds. The Blue Iris "Find/inspect..." process doesn't work right on Doorbirds. So if you do it for an already correctly configured and working Doorbird cameras that I'm using (see models in the start of this thread) you'll get the rainbow screen for that camera.

For the Doorbird models I have have listed at the beginning of this thread, the IP address field needs to read "rtsp:/" then "IP address of the Doorbird/mpeg/media.amp" with Make field indicating "Generic/ONVIF", the Model field indicating "*RTSP H.264/H.265/MJPG/MPEG4" and the "Main" field within the "Stream Profiles" section of that same dialog/configuration screen indicating "(default}" with the directory as "mpeg/media.amp".

After completing this for all cameras, my CPU % dropped to 66% even when doing a Remote Desktop to that Windows 10 x64 box running Blue Iris even while running the Blue Iris GUI on that box. Problem Solved - thank you Ajwitt. Hope others can leverage the information. Know that I appreciate the users on this site!!!!

 

[sebastiantombs]

Glad you found the problem but I still think you should look at sub streams and get that processor down to 20% or lower.

 

[bp2008]

For a long time now, Blue Iris has been programmed to turn off hardware acceleration on a per-camera basis if the camera experiences certain kinds of failures. Unfortunately some failures are temporary while Blue Iris's "solution" is permanent until you notice and turn HW decode back on.

 

[Mike Newman]

BP2008 - that good information to know! Thank you!

 

[ktcanuck]

Looks like he fixed it 5.3.7.12.

 

[bp2008]

For what its worth, I just updated an old system that was running 5.0.6.7, updated all the way to 5.3.7.12, and CPU usage did not change in a meaningful way. Was about 22% before, and still around 22% after the update.

 

[Mike Newman]

BP2008, relative to your upgrade keeping state the same before and after upgrade, I'm wondering based on your earlier comments about HW accelerated decoding being automatically turned off if there are issues, I wonder if I had some issue, unknown to me, that caused the change prior or just after the upgrades that caused same. Right now, after making the changes to get Blue Iris CPU utilization back down (as described in the Root Cause Analysis and Solution I previously posted above) and upgrading to 5.3.7.12, my CPU useage is still around the mid 60%s. Thanks for everyone's input.

 

[silencery]

I'm also seeing a huge CPU spike with recent updates. Went from 5-10% to over 70-80%. Was already on substreams and verified they're still being applied. Trying upgrade to 5.3.7.13 now to see if that solves the problem.

 

[ajwitt]

Did you confirm you are running the lower substream #1 and not the higher substream #2?

 

[silencery]

Yup, confirmed the correct URLs for proper substreams. Half my cameras only have 1 substream anyway.

 

[jsnicholas]

I'm also seeing a huge CPU spike with recent updates. Went from 5-10% to over 70-80%. Was already on substreams and verified they're still being applied. Trying upgrade to 5.3.7.13 now to see if that solves the problem.

I too am having trouble with my system. Sometime within the last week I went from about 40% CPU to 98% CPU. Streams are occasionally dropping now. My system has been working fine for several years with minor tweaks and regular software updates. My configuration has not changed for 6 months. I am not using substreams and did not even know about them until now, but the is beside the point. Something changed with a recent update. I have looked at the hardware acceleration and they were all "default" . I tried to set it to a couple different settings without luck. I thought I upgraded to 5.3.7.13, but it still says 5.3.7.12. I did want I thought was a clean install from the website.

UPDATE: I manually installed the update for 5.3.7.13 and now I have the latest version, but the problem is still there. 100% CPU.

 

[Dave Lonsdale]

Similar problem here too with 5.3.7.12. Most camera streams stop working, this time one camera of thirteen has cancelled Intel HA. OK for a couple of days and then see iPad app pictures. Has now happened twice since updating to v12. Roll on v14...