Blue Iris UI3

It is also worth noting that UI3 can only download clips exactly as they exist as files on your server. It can't convert to mp4 or export just a single alert from a clip that contains more than one alert.

So if you download an alert what you actually get is the clip that contains it.
Ok so I assume since I am recording this cam 24/7 that it will be the file size of the max allowed before it splits them.
Now I know. Thanks!
 
So I managed to get it to login behind an Apache Reverse proxy, but my issue is now, that it shows all the UI, but camera feeds fail. Is there other ports etc that maybe used? I am only proxying the port 8000 for BlueIris.

Update: It works fine using JPEG streaming. If I switch to any of the H.264 streams it times out the feeds.
 
So I managed to get it to login behind an Apache Reverse proxy, but my issue is now, that it shows all the UI, but camera feeds fail. Is there other ports etc that maybe used? I am only proxying the port 8000 for BlueIris.

Update: It works fine using JPEG streaming. If I switch to any of the H.264 streams it times out the feeds.

It all operates on the same port, but h.264 streaming works with a long-running continuous connection whereas jpeg streaming is a series of very short connections. Probably your proxy server is trying to load the entire response before forwarding it to your browser and you need it to do streaming responses.
 
  • Like
Reactions: fenderman
Nope that's not it.

Still trying to work it out but I can force a login (its a session so I log into another subdomain first then go in), but I am getting allot of 401 errors in Chrome Dev Tools. For example, one the address's is (https://nvr.example.com/video/index...2f71408399b4d793c73&audio=0&stream=0&extend=2)

If I turn off Apache Auth, then all works fine. So the files are there and such, it has something to do with the authentication. Either UI is overriding the session credentials or there are different protocols at play. Like is it using web sockets at all? If it is using another protocol other than HTTP or https then I have to account for them in the reverse proxy settings.

And yes, I renamed my session name to avoid a conflict.
 
It all operates on the same port, but h.264 streaming works with a long-running continuous connection whereas jpeg streaming is a series of very short connections. Probably your proxy server is trying to load the entire response before forwarding it to your browser and you need it to do streaming responses.

BTW, more than happy to give you access to see for yourself what the errors are.
 
No web sockets. I wanted to use web sockets but couldn't get Ken to implement a web socket server. And it worked out anyway since most browsers have since adopted http response streaming capabilities via the fetch API.

If you PM me login details I will give it a try and see if I can find the problem.
 
Buttons for zooming would just be a step in the wrong direction.

I now what you mean, but as a quick fix without exploring touch zoom for the camera image they do actually work quite well. I've modified my UI3 and put them on the streaming quality menu so they don't clutter up the UI.

I can now zoom in on Android without losing quality or the rest of the UI which works for a couple of our use cases.
 
I
No web sockets. I wanted to use web sockets but couldn't get Ken to implement a web socket server. And it worked out anyway since most browsers have since adopted http response streaming capabilities via the fetch API.

If you PM me login details I will give it a try and see if I can find the problem.
ll send you the details once I have the NVR back up and running. Doing some server maintenance at the moment.
 
Has anyone though their streaming options changed by themselves?

I've ended up on jpeg instead of H.264 streaming on several occasions on our Android devices (mostly home screen icon for direct web view). At first I put it down to finger trouble but its happened enough times for both my wife and I that I am wondering if there's some other scenario that could trigger this, perhaps around refresh after session timeout etc.
 
Last edited:
What do you mean?

I mean I don't know what your phone is so I can't say for sure if UI3 will work on it.

If it is anything even halfway modern then yeah it will probably work fine.

The official mobile apps ($10) are a lot more efficient though since they have access to more efficient video decoders.
 
Has anyone though their streaming options changed by themselves?

I've ended up on jpeg instead of H.264 streaming on several occasions on our Android devices (mostly home screen icon for direct web view). At first I put it down to finger trouble but its happened enough times for both my wife and I that I am wondering if there's some other scenario that could trigger this, perhaps around refresh after session timeout etc.

That happened to a friend of mine who used a older version of IPCAM viewer on his phone...as soon as he accessed the cam it switched the stream.
 
I think something was lost in translation there, but if you are asking when this will be included in a Blue Iris update, then I've been told "end of year".
Have you been given any new information on when this might be included in a Blue Iris update?
 
That happened to a friend of mine who used a older version of IPCAM viewer on his phone...as soon as he accessed the cam it switched the stream.

This doesn't make any sense to me.

Have you been given any new information on when this might be included in a Blue Iris update?

Nope.

No he hasn't, as of last week.

Correct.

Any plans for Alexa support or will that come with the official Blue Iris release?

Blue Iris already has support for this. I have nothing to do with it.