Blue Iris UI3

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,111
Location
USA
Have you given any further consideration to workarounds for this issue? I've tried the suggestion to use Firefox on mobile devices (it's already my preferred browser in a desktop), and although it initially looked promising, the error message did eventually show up there as well. If I switch to the Javascript player, I eventually see the orange clock timer symbol, despite lightly lengthening the timeouts (ie: within reason).
Well if you used an HTTPS reverse proxy server (such as nginx or stunnel or a cloudflare tunnel) then you could try the "WebCodecs" player.

My "todo" list for UI3 has been growing, but I have been busy with other things. This will get tweaked eventually :)
 

ericINT

Getting the hang of it
Joined
Oct 20, 2022
Messages
26
Reaction score
30
Location
San Antonio
I have my BI machine using a HTTPS reverse proxy server (Nginx Proxy Manager) and access my system via the UI3 interface from many external locations. However, at work if I login I get very slow to load feeds and stuttering. This is not a bandwidth issue, but instead something on the corporate machine or network limiting the type of stream UI3 is using.

Is there anything I could look at changing on BI/UI3/reverse proxy that could help prevent this reduction in performance? This is likely a bit vague of a request, so if more information is needed please point me in the right direction.
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,111
Location
USA
@ericINT

You can see a working nginx configuration example here: Using UI3 with a reverse proxy server

This may be a case where Nginx Proxy Manager makes your task harder since last time I used it, it only has a very simple configuration interface that does not expose all the nginx options that are available or even show which are being used.

It sounds like your nginx configuration might be trying to buffer the data it proxies, which can prevent UI3 (and the Blue Iris mobile apps) from live streaming properly as nginx will basically hold the video stream hostage for some arbitrary amount of time, causing exactly what you describe, very slow streaming loading and stuttering. A similar thing can also happen with some anti-malware services that do the same thing, buffering HTTP responses in order to scan them before delivering them.
 

ericINT

Getting the hang of it
Joined
Oct 20, 2022
Messages
26
Reaction score
30
Location
San Antonio
@bp2008

The advanced section in the proxy host of the Nginx Proxy Manager allows you to change the finer details. My configuration for the proxy manager is a bit more advanced due to using Authentik as a SSO in front of Blue Iris.


------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
# Increase buffer size for large headers, **turned off
# This is needed only if you get 'upstream sent too big header while reading response
# header from upstream' error when trying to access an application protected by goauthentik
proxy_buffers 8 16k;
proxy_buffer_size 32k;
proxy_buffering off;
tcp_nodelay on;


# Make sure not to redirect traffic to a port 4443
port_in_redirect off;

location / {
# Put your proxy_pass to your application here
proxy_pass http://192.168.1.5:45568;
# Set any other headers your application might need
proxy_set_header X-Forwarded-For $remote_addr;

##############################
# authentik-specific config
##############################
auth_request /outpost.goauthentik.io/auth/nginx;
error_page 401 = @goauthentik_proxy_signin;
auth_request_set $auth_cookie $upstream_http_set_cookie;
add_header Set-Cookie $auth_cookie;

# translate headers from the outposts back to the actual upstream
auth_request_set $authentik_username $upstream_http_x_authentik_username;
auth_request_set $authentik_groups $upstream_http_x_authentik_groups;
auth_request_set $authentik_email $upstream_http_x_authentik_email;
auth_request_set $authentik_name $upstream_http_x_authentik_name;
auth_request_set $authentik_uid $upstream_http_x_authentik_uid;

proxy_set_header X-authentik-username $authentik_username;
proxy_set_header X-authentik-groups $authentik_groups;
proxy_set_header X-authentik-email $authentik_email;
proxy_set_header X-authentik-name $authentik_name;
proxy_set_header X-authentik-uid $authentik_uid;
}

# all requests to /outpost.goauthentik.io must be accessible without authentication
location /outpost.goauthentik.io {
proxy_pass # ensure the host of this vserver matches your external URL you've configured
# in authentik
proxy_set_header Host $host;
proxy_set_header X-Original-URL $scheme:/$http_host$request_uri;
add_header Set-Cookie $auth_cookie;
auth_request_set $auth_cookie $upstream_http_set_cookie;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
}

# Special location for when the /auth endpoint returns a 401,
# redirect to the /start URL which initiates SSO
location @goauthentik_proxy_signin {
internal;
add_header Set-Cookie $auth_cookie;
return 302 /outpost.goauthentik.io/start?rd=$request_uri;
# For domain level, use the below error_page to redirect to your authentik server with the full redirect path
# return 302 }
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


I only see this behavior at work which of course has the corporate nannies. UI3 functions from other locations, so I had always assumed some corporate firewall/anti-malware/bandwidth/video limiter/etc was to blame, but had not looked into if there was a potential workaround.
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,111
Location
USA
@bp2008

The advanced section in the proxy host of the Nginx Proxy Manager allows you to change the finer details. My configuration for the proxy manager is a bit more advanced due to using Authentik as a SSO in front of Blue Iris.


I only see this behavior at work which of course has the corporate nannies. UI3 functions from other locations, so I had always assumed some corporate firewall/anti-malware/bandwidth/video limiter/etc was to blame, but had not looked into if there was a potential workaround.
Nothing sticks out to me as problematic in that configuration.

There's so much that could be going on in a corporate environment in terms of web proxying for virus scanning and other purposes, it could be tough to track down the cause.

Blue Iris's video streaming uses a long-running HTTP response to deliver the streaming video, which is highly unusual (in that no other video streaming service I can think of does anything like that). Therefore it is a case that some HTTP proxy servers simply were not designed to handle appropriately.
 

modplan

n3wb
Joined
Mar 22, 2019
Messages
4
Reaction score
0
Location
US
@bp2008 I have an odd issue that has cropped up in recent versions of BI that I'm hoping you can help with. This seems to only happen on BI versions 5.8+. I was running 5.7 for a while to get around this problem, but needed to upgrade BI to take advantage of other new features and bug fixes.

I have 6 cameras using sub and main streams. These cameras have motion sensors off, and are triggered via external HTTP triggers (PIR motion sensors around my property) as well as the camera's ONVIF triggers via Dahua IVS. This generates my "confirmed" alerts. For example "Driveway"

I then clone all 6 cameras and turn the BI motion sensor on for all 6 of the clones. These cloned cameras do not generate alerts, but instead record whenever BI motion sensor is triggered using the sub stream. For example "DrivewayMotion"

This setup that I've been using for years allows me to see "confirmed" alerts that are externally triggered, while still being able to separately browse any motion clips from the cloned cameras in case I need to see something that did not trigger an alert. By using the cloned cameras I can also easily tell the difference between clips that were triggered by an external source as they will be named "Driveway" vs the ones triggered by BI's motion sensor as they will be named "DrivewayMotion".

The Problem: In BI versions 5.8+, about 90% of the time if I click on an alert in UI3 (from the main cameras that are not using the sub stream for motion detection), especially often while the alert is still in progress, the UI3 will show the substream for the alert. I tried disabling "Record sub-stream if available" in BI on these main cameras and that made a difference. But now the alert videos are played at the Anamorphic size (848 x 480 in my case) instead of the 2688 x 1520 resolution of the cams. The video seems to be forced crudely down to 848 x 480, as the aspect ratio seems off the the video is blocky. The odd thing is, if I hard refresh the browser while the alert is playing, it will play at the full 2688 x 1520 resolution as expected. It's almost like the sub stream, or the sub stream anamorphic size if substream recording is off is getting cached or forced until I hard refresh the page. Also, this does not seem to happen, or happens far far less often, if I try to play an alert that is older and not still recording.

Any ideas what I can do to get around this problem? Is there a setting somewhere I am missing? My clone setup and external triggers is probably a unique setup, but I'm hoping there is just some setting I'm missing to fix this, though I feel like I've toggled and tried almost everything.
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,111
Location
USA
@modplan I'm not sure what is going on based on the symptoms you describe. I was unable to reproduce such an issue, although I did not try cloning a camera so maybe that is part of the issue.

To gather a bit more information, try having the "Stats for nerds" panel open in UI3 (right click the video, "Stats for nerds" is an option in the context menu). The second line is "Stream Resolution" which tells you the resolution of the video stream that Blue Iris sent, and the resolution that UI3 believes is the max available.

1718820117636.png

I suspect Blue Iris is creating the alert object incorrectly (perhaps just with the wrong resolution set in the metadata) and fixing it after a few seconds, but during those early seconds if the alert metadata gets sent to UI3 it will be cached and UI3 will believe that is the maximum resolution available for the alert, so it doesn't ask for the resolution to be any higher.

By the way if you click the "Clips" tab this reloads the clip list without you needing to reload the whole webpage. In this case either method of reloading the alert list would cause UI3 to get a completely new copy of the alert list, along with the updated resolution.
 

modplan

n3wb
Joined
Mar 22, 2019
Messages
4
Reaction score
0
Location
US
@modplan I'm not sure what is going on based on the symptoms you describe. I was unable to reproduce such an issue, although I did not try cloning a camera so maybe that is part of the issue.

To gather a bit more information, try having the "Stats for nerds" panel open in UI3 (right click the video, "Stats for nerds" is an option in the context menu). The second line is "Stream Resolution" which tells you the resolution of the video stream that Blue Iris sent, and the resolution that UI3 believes is the max available.

View attachment 196848

I suspect Blue Iris is creating the alert object incorrectly (perhaps just with the wrong resolution set in the metadata) and fixing it after a few seconds, but during those early seconds if the alert metadata gets sent to UI3 it will be cached and UI3 will believe that is the maximum resolution available for the alert, so it doesn't ask for the resolution to be any higher.

(By the way if you click the "Clips" tab this reloads the clip list without you needing to reload the whole webpage.)

I just did a test, stats for nerds shows 848x480 (Native: 848x480)

Once the recording has stopped, after clicking the "Clips" tab, and then clicking the alert again so that it starts over, it shows 2688x1520 (Native: 2688x1520). I tried multiple times and it did not switch to 2688x1520, in these cases, until the alerts were finished recording.

However, during the recording, if I do a hard browser refresh, the clip will play at 2688x1520. However if I then click the alert again to start it over, before recording is finished, it goes back to 848x480.
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,111
Location
USA
I just did a test, stats for nerds shows 848x480 (Native: 848x480)

Once the recording has stopped, after clicking the "Clips" tab, and then clicking the alert again so that it starts over, it shows 2688x1520 (Native: 2688x1520). I tried multiple times and it did not switch to 2688x1520, in these cases, until the alerts were finished recording.

However, during the recording, if I do a hard browser refresh, the clip will play at 2688x1520. However if I then click the alert again to start it over, before recording is finished, it goes back to 848x480.
Hmm. It sounds like the resolution stored in the clip object is correct while the resolution stored in the alert object is incorrect before the alert is finalized. That probably doesn't make a lot of sense to you. I don't want to lose you in the technical details. Anyway when you reload the page, UI3 sees the URL parameter rec which contains the alert ID and millisecond offset where you were at when you reloaded the page.

example:
1718821685440.png

UI3 then uses Blue Iris's "clipstats" API command to query the clip metadata for the clip with the given ID (in my example the database ID string is "@6515022633"). Blue Iris returns the metadata for the clip object which the alert points at, which is very similar to an alert object but not the same thing exactly. In particular a clip object contains the current length in milliseconds of the clip, which is necessary for UI3 to properly build the seek/scrub bar. Anyway I digress. Once UI3 has the clip object, UI3 seeks to the location specified in the rec parameter and begins playback. It is a somewhat different code path than when you click on an alert in the alert list. When you click an alert in the alert list, it seems that UI3 is learning the native resolution of the alert from the alert object, but that resolution is wrong before the alert is finalized, causing UI3 to request a stream at too low of a resolution.

Only Ken at Blue Iris support will be able to fix this issue really. You should send them an email.

Aside, if you're getting bad blocky artifacts at 848x480 resolution, you should try using a higher quality streaming profile in UI3. The "VBR" profiles are rather low quality by design and it is very apparent when the video is low resolution and being upscaled to fit your screen.
 

modplan

n3wb
Joined
Mar 22, 2019
Messages
4
Reaction score
0
Location
US
Thanks for all the info @bp2008!

I'm going to see if removing my cloned cameras makes any difference to see if that makes any difference with the resolution set in the alert object. I originally set up this convoluted clone set up to work around another bug in BI, but that was years ago, and I believe that bug has been fixed now. My wife and I have just gotten used to how things work so I've left it.

If I can't get all that working, I'll email Ken.

Thanks again for the detailed reply!

Update: Disabling and deleting the cloned cameras seems to make no difference. So it doesn't appear this has anything to do with my setup. Odd that I'm seeing this, but others are not. It must be some setting somewhere. Shot Ken an email.
 
Last edited:
Top