Blue Iris Updates (64 bit)

Blue Iris Updates - Official Thread 6.0.9.15

I just checked my defender history, and I have no log of it. I am running 6.0.9.6 as well. Was it the update file itself it barked at?
I turned Smart App control on for one of my systems (it was already off) and when I tried to launch the BI application id was blocked, so I turned Smart App control back off again!
 
For me Defender is flagging the temp file BlueIris.exe that gets extracted from the downloaded updates files as being infected with Trojan:Win32/Sabsik.FL.A!ml

I have Smart App disabled.
 
From the other forum -

"by jakev383 » Tue Jul 21, 2026 2:08 pm

And BlueIris Support was fast to respond to my email:

Good morning. We had an issue with the latest exe not being signed correctly, but rest assured there is no virus. Please re-apply the latest update through Check for News and Updates, or you can download it directly via
Bryan
Blue Iris Technical Support Specialist"
 
Edit Zone Map missing in version 6.0.9.6
I needed to adjust a zone this morning and noticed the control was missing. I went back to version 6.0.9.5, and it was there. Was the control moved elsewhere? I looked and could not find it. For the time being I will stay with 6.0.9.5

zone-map.jpg
 
  • Like
Reactions: Techie007L
The
6.0.8.6

Undocumented under-the-hood change


Starting with v6.0.8.6 (6/30/2026), Blue Iris now uses a rolling 3-second average when calculating the bitrate macros %k and %007. Ken has also confirmed that the FPS macros %f and %006 were similarly updated. He noted that the changes were suggested by AI.

Previously, the calculation was based on 10 one-second buckets of frame data.

Users graphing these macros should expect smoother values than in previous releases, even though the underlying camera behavior is unchanged.

It's worth noting that these macros represent values measured and averaged by Blue Iris from the received video stream, not values reported directly by the camera.
Quoting myself to provide an update on this topic...

After running 6.0.9.6 for about a week, I compared approximately 3.1 days of logged data (about 755 six-minute samples per camera for 9 cameras) from the legacy implementation against the current implementation on my system (6 wired Ethernet cameras and 3 powerline Ethernet cameras).

The results showed:
  • Reported bitrate variability decreased (improved) by roughly 35–67%.
  • Reported FPS variability decreased (improved) by roughly 41–59%.
  • The gap between my wired and powerline cameras narrowed, while the powerline cameras still remained measurably more variable, as expected.
Overall, the reported values are noticeably steadier while still reflecting (i.e., not obscuring) real differences between cameras. In particular, non-sensical high FPS values have been eliminated.

I shared my results with Ken, and he was kind enough to explain the new implementation (he even shared his code for the FPS macro --- DM me if you're curious).

He explained that the bitrate macros now simply measure the amount of data received over approximately a 5-second window, and calculate the corresponding bitrate. The FPS macros handling is a bit more complex. They similarly measure frames received over roughly a 5-second interval, then apply a light exponential smoothing between successive measurements to reduce short-term fluctuations. Additionally they perform an interval-domain smoothing for keyframe rates. This replaces the earlier implementation, which used a different averaging approach.

Bottom line: My measured results show that the current implementation produces substantially steadier bitrate and FPS values than the legacy macros.
 
Last edited:
@jaydeel Now if only we could get the bitrate figures expressed in bits (kilobits and megabits, like on all cameras and networking equipment) instead of bytes! After all, it is "bitrate", not "byterate"...