Blue Iris UI3

[GoodToGo]

You can list the private LAN IP addresses as it does not tell anyone anything - they are the same as everyone else. The IP address of your service provider for your WAN is what you don't provide...Everything on the inside past the modem is fine to put out. Everything on the inside, the local will fall under these ranges and you are not telling anyone anything about how to hack your system because these ranges are reserved for the "home side" of the service so every home internally will be within this same range):

10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255

And it is usually a number typo someone has with their IP address that causes troubleshooting to take longer because someone doesn't show the IP address and that extra 1 sticks out like a sore thumb to someone helping troubleshoot.

Thanks for that, I erred on side of caution.

 

[sp0457]

Hi @bp2008, on recorded videos when seeking, the video quality is extremely compressed and low (with severe H.264 macro blocking so much so that it's hard to see what is going on). No matter what settings are used (like adjusting Blue Iris' encoder or UI3 profiles), nothing seems to change this ultra-low encoding profile that is used only during seeking (the actual recording playback is ok, this only affects seeking of recordings within UI3). I don't use sub-stream recordings and the UI3 "Seek with Sub Stream" setting is off.

A few years ago seek quality was ok but at some point it became a mess. This issue has persisted no matter the version of Blue Iris and UI3. Currently on UI3 version 249 and Blue Iris version 5.8.4.2. I tried many different encode settings (and a reset at one point) but could not find a fix or a solution by search. I want to finally ask if maybe I can do something about it, perhaps using an override in the JS to use a specific encoding profile for seeking?

 

[bp2008]

Hi @sp0457

UI3's seeking (while you are actively holding down the mouse button and dragging the seek bar) is not done with H.264 since there's no API available to do that properly. While you seek, every frame is a jpeg snapshot.

If you were using a Jpeg streaming profile, I think it would use that profile to determine the quality to use for seeking.

But when you have an H.264 profile selected, UI3 does it differently. If I recall, the quality of those frames while seeking is dependent on the average bit rate that was achieved during the last few seconds of H.264 video streaming. The idea was, if the bit rate was very high, then the user is probably on a fast connection so getting large jpeg images won't be too laggy. But if the bit rate was very low, that indicates there might not be much bandwidth available so UI3 would try to use a very low quality for those jpeg images whiel seeking.

It may be time to adjust the logic that decides the quality. Or maybe I just need to add a "seeking quality" field to the streaming profile configuration, and not have it try to choose the quality dynamically anymore.

You already turned off the Seek with Sub Stream setting. That is good. The only other thing you can control at this time is to choose a higher quality streaming profile like "2160p" as this should in most cases result in a high enough video bit rate that the jpegs look good. Are you not seeing that behavior on your system? Do note that the "VBR" profiles typically function with a very low bit rate and this may adversely affect the quality that is used while seeking. But the profiles without "VBR" in the name have higher quality settings which typically yield a much larger bit rate, and therefore higher quality seeking.

 

[sp0457]

Hi @sp0457

UI3's seeking (while you are actively holding down the mouse button and dragging the seek bar) is not done with H.264 since there's no API available to do that properly. While you seek, every frame is a jpeg snapshot.

If you were using a Jpeg streaming profile, I think it would use that profile to determine the quality to use for seeking.

But when you have an H.264 profile selected, UI3 does it differently. If I recall, the quality of those frames while seeking is dependent on the average bit rate that was achieved during the last few seconds of H.264 video streaming. The idea was, if the bit rate was very high, then the user is probably on a fast connection so getting large jpeg images won't be too laggy. But if the bit rate was very low, that indicates there might not be much bandwidth available so UI3 would try to use a very low quality for those jpeg images whiel seeking.

It may be time to adjust the logic that decides the quality. Or maybe I just need to add a "seeking quality" field to the streaming profile configuration, and not have it try to choose the quality dynamically anymore.

You already turned off the Seek with Sub Stream setting. That is good. The only other thing you can control at this time is to choose a higher quality streaming profile like "2160p" as this should in most cases result in a high enough video bit rate that the jpegs look good. Are you not seeing that behavior on your system? Do note that the "VBR" profiles typically function with a very low bit rate and this may adversely affect the quality that is used while seeking. But the profiles without "VBR" in the name have higher quality settings which typically yield a much larger bit rate, and therefore higher quality seeking.

@bp2008

Thanks for the reply. Yes, seeking with mouse dragging and using a H.264 profile (CBR, 6000 kbps, 1080p that is defined on the server) results in very compressed video. I set this up server side so that all my home devices would have the same default profile. After reading your post, I set the same bit rate limit within UI3 (even though it's already set on the server) and the seek video quality is now ok. So setting the bit rate limit in UI3 is what fixes it (all other settings blank or as inherit). Thank you for the help.

 

[bp2008]

@bp2008

Thanks for the reply. Yes, seeking with mouse dragging and using a H.264 profile (CBR, 6000 kbps, 1080p that is defined on the server) results in very compressed video. I set this up server side so that all my home devices would have the same default profile. After reading your post, I set the same bit rate limit within UI3 (even though it's already set on the server) and the seek video quality is now ok. So setting the bit rate limit in UI3 is what fixes it (all other settings blank or as inherit). Thank you for the help.

As you've perhaps now noticed, all of UI3's default streaming profiles override the bit rate limit and resolution limit of the serverside profiles. And most also override the encoding quality.

 

[sp0457]

Thanks @bp2008,

Another question. This may be more of a blue iris issue than UI3 but thought I'd ask: When using sub-streams, UI3 defaults to the frame rate and audio of the sub-stream when viewing the main camera stream. This is especially odd when using direct to wire when there is no encoding from Blue Iris. As a result, the main stream is choppy because the sub-stream has a lower frame rate so I have to set the sub-stream to the same exact frame rate and audio quality as the main stream to avoid this issue.

The primary reason for using sub-streams is to minimize CPU usage by having lower res video and frame rate for motion detection and when a group stream requires it. It'd be ideal if sub-streams can also have lower frame rate and no audio. Is this something that needs to be done by Blue Iris and or can it be addressed by UI3?

 

[bp2008]

Thanks @bp2008,

Another question. This may be more of a blue iris issue than UI3 but thought I'd ask: When using sub-streams, UI3 defaults to the frame rate and audio of the sub-stream when viewing the main camera stream. This is especially odd when using direct to wire when there is no encoding from Blue Iris. As a result, the main stream is choppy because the sub-stream has a lower frame rate so I have to set the sub-stream to the same exact frame rate and audio quality as the main stream to avoid this issue.

The primary reason for using sub-streams is to minimize CPU usage by having lower res video and frame rate for motion detection and when a group stream requires it. It'd be ideal if sub-streams can also have lower frame rate and no audio. Is this something that needs to be done by Blue Iris and or can it be addressed by UI3?

There is nothing I can do about those issues, as it is all within the domain of Blue Iris and is not something UI3 is involved with.

The one about sub stream audio is new to me. I was under the impression that a camera's audio came from the main stream, period. It is mentioned right in the first sentence of the Dual streaming section of Blue Iris's help file.

 

[sp0457]

There is nothing I can do about those issues, as it is all within the domain of Blue Iris and is not something UI3 is involved with. The one about sub stream audio is new to me. I was under the impression that a camera's audio came from the main stream, period.

Understood. Yes, the audio issue surprised me too. Anyway, thanks for replying.

 

[actran]

UI3 version 265, Blue Iris version: 5.8.4.5
I noticed this red speaker icon (I highlighted with yellow rectange in screenshot).
Why does it appear every time trigger happens (red lightning icon), even for external trigger?
I think this was introduced in a recent release?!?! What does it mean?


BTW, I don't have audio trigger source enabled.

 

[bp2008]

@actran That icon has been in for a very long time. It is supposed to only appear during an audio trigger, only if you've enabled the icon in UI3's settings > Event-Triggered Icons. It does look like it is bugged. I was able to reproduce the issue myself and UI3 is behaving as intended with the info Blue Iris gives it. But clearly something is wrong. I've sent Ken an email to figure it out.

 

[bp2008]

@actran I've heard back from Ken. There was a coding error in Blue Iris so it was sending the wrong value in the field that tells the client app what the trigger sources were. It will be fixed in BI 5.8.5.x.

 

[actran]

@bp2008 You are so awesome. Thank you.

 

[piconut]

I haven't changed anything on my setup, as far as I can remember in the last 6 months but just in the last couple of months, I've noticed that about half the time when I try to log into the UI3 web interface using Chrome on Android, that it prompts me for a username and password even though I've had my phone memorized those. It will work fine for several days and maybe a week and then all of a sudden it prompts for credentials repeatedly for several days. Is there a way I can hard code my credentials into the URL parameter or some other way?

Edit: I should add that this doesn't happen when I'm using Chrome on my Windows desktop or laptop, only on my Samsung S21.

 

[bp2008]

@piconut

Yes, if you disable the "secure session keys" function in Blue Iris settings > Web server > Advanced, then you can embed credentials into your bookmarked URL. Embed credentials on Blue Iris Web Server URL

I don't recommend that though.

There are a number of things that could interfere with automatic login.

Are you using "Log in automatically" on Blue Iris's login page? If not then I can't help you. lol.

If you are, then the credentials are being stored in your browser's localStorage associated with the hostname. In fact, the state of the "Log in automatically" toggle switch is also stored there.

If you are finding yourself on Blue Iris's login page and there's no error message and it isn't trying to log you in ...

• If the "Log in automatically" toggle switch set to "no", then it indicates your localStorage probably got cleared. This typically only happens if you clear cookies. Maybe your browser or a security extension is doing that periodically.
• If the "Log in automatically" toggle switch set to "yes", there are a few ways that can occur by design.

* If you just clicked "Log Out" in UI3, that loads the login page with the URL parameter "autologin=0" which temporarily disables the auto login just for that one page load and leaves the auto login setting still set to "yes". The "autologin=0" URL parameter should disappear immediately upon page load, so you wouldn't necessarily see it in the address bar.
* If you load the login page by some other means (e.g. by loading a bookmark that points explicitly at login.htm) and UI3 is or was open within the last few seconds, the login page is supposed to not log you in automatically. Typically you'd get a message saying you have an existing session and to click here to use it.

 

[EvanVanVan]

In the full Blue Iris app, you can right click a cancelled alert and Confirm Alert and the alert moves to the Confirmed Alerts list.

In UI3, you can right click alerts and Mark as AI-Confirmed but all that appears to do is give the alert a checkmark? It doesn't move the alert to the Confirmed Alerts. It works the same on already confirmed alerts, the option is to Mark not Unmark (which adds a checkmark).

Are these supposed to be equivalent functions between the app the web ui? Maybe it's just a limitation of what's possible via the web ui? Is there a way of actually confirming the alert (and moving it to the correct list)?

Thanks

 

[bp2008]

Hi @EvanVanVan

Thanks for reporting the issue!

Yes, those functions are supposed to be equivalent. Something is broken. I've just sent Ken a support request detailing what is going on and asking for his input on the matter.

 

[DarkHelmet]

Whats the best way to lock down certain mainMainItems to admins only? Ive been able to find where the buttons are created in ui3.js such as new DropdownListItem({ cmd: "ui_settings".... and how items are controlled with if (sessionManager.IsAdministratorSession()) but I'm not sure how to bring it together in the overrides js. I'm trying to stop people being able to locally override settings I've already created overrides for globally. I believe I could change each settings "Options Window" setting to false one by one, but I think that would also affect admins..

Similarly, I'd like to hide the "playbackSettingsButton" for non-admins so folks can't change the quality setting I've dictated.

Thanks!

 

[bp2008]

@DarkHelmet

Hmm, tough one. None of this is very straightforward to implement via the overrides system, but it can all be done. Apologies for the forum mangling the comment lines. It deletes double forward slashes and replaces them with single forward slashes so I've put in a lot of extra slashes on the code comments.

Here's one way. First we'd hook into the dropdown boxes initialization routine and configure every item in the main menu to have a predictable unique CSS class. Then upon login success (which is also the event that UI3 raises after receiving session status), you can inject css to hide certain buttons.

Local Overrides Sample: Hide some Main Menu items from non‐admin users

A powerful, modern HTML5 web interface for Blue Iris. - bp2008/ui3

github.com

The above script also injects css to hide the playback settings button only for non-admins.

I'm trying to stop people being able to locally override settings I've already created overrides for globally. I believe I could change each settings "Options Window" setting to false one by one, but I think that would also affect admins..

That is correct. Again this is a little messy but it can be done. You'd need to listen for UI3 to raise the "Login Success" event and paste your OverrideDefaultSetting calls there. Like this:

Local Overrides Sample: Hide some UI Settings from non‐admin users

A powerful, modern HTML5 web interface for Blue Iris. - bp2008/ui3

github.com

Edit: The above scripts are now in UI3's github documentation.

 

[DarkHelmet]

This is great! If I'm understanding correctly, I don't need to use both of these methods. I can either use the 'myCss' classes you made at the top OR use the more standard override format within your admin checker function from the bottom. Is that right?

 

[bp2008]

Those each serve different purposes. Use whichever you want or both.