Look at BI's status window, Connections tab to see the IP being used to connect. In some circumstances it is possible for that to be different than you expected.
Blue Iris UI3
- Thread starter bp2008
- Start date
199 is test server
10 is production and the one I am having a login requirement
151 are VNC
2 is HomeSeer
146 is tablet for UI3
Hmm, well I never run with "Use secure session keys and login page" unchecked so I'm not fully aware of how that behaves.
But I would expect your tablet there to be given an administrator session automatically because of being a whitelisted address, and even if that function was not working then it should be getting an anonymous session because of being a LAN address.
Lets back up a bit.
What does it look like when you are asked for credentials? Can you screenshot that?
This is just the web browser informing you that you didn't use HTTPS, which is completely normal because Blue Iris does not support HTTPS natively with its web server.
But I would expect your tablet there to be given an administrator session automatically because of being a whitelisted address, and even if that function was not working then it should be getting an anonymous session because of being a LAN address.
Lets back up a bit.
What does it look like when you are asked for credentials? Can you screenshot that?
This is just the web browser informing you that you didn't use HTTPS, which is completely normal because Blue Iris does not support HTTPS natively with its web server.
I am traveling and accessing my network via zerotier. First time I have gotten credidential request as well.
@bp2008 No rush.
I see with BI 5.6.3.0 (UI3 v223) that I can get audio during single camera playback on Timeline tab. Very nice! But when I toggle to a group view, the audio does not work, EXCEPT if I jump to current time---meaning, audio works in group view during live playback but not when going back to old date/time. Is this a known limitation?
I see with BI 5.6.3.0 (UI3 v223) that I can get audio during single camera playback on Timeline tab. Very nice! But when I toggle to a group view, the audio does not work, EXCEPT if I jump to current time---meaning, audio works in group view during live playback but not when going back to old date/time. Is this a known limitation?
I completely started from scratch and rebuild my production computer. I think all the changes I made for Deepstack, etc. caused instability for BI.
All is working as expected. Thanks.
All is working as expected. Thanks.
I just tried. You're right, no audio stream is given for group timeline video. I'd say this behavior is consistent with the release notes:
Hopefully timeline multi-camera audio is coming soon, but to be fair I think in a lot of systems this is less valuable since there's often a really noisy camera in the mix, or the streams are out of sync enough to make the audio a mess when you hear all the cameras at the same time.
@bp2008 Just case you did not know, for each group, when I edit group config, I can control which camera(s) will provide audio for that group. Typically, I select only 1 camera audio for each group so that I don't have multiple audio streams during group view.
Nice. I had forgotten about that.
How can I optimize the stream to hopefully avoid network slow down on an iPad using Wi-Fi and 5Ghz?
The default "VBR" streaming profiles in UI3 will use far less bandwidth than most of the others (at the cost of reduced quality). Also can help to change the H.264 player to "JavaScript" in the UI settings panel.
Otherwise if you want to absolutely eliminate delay and don't mind having a low frame rate and higher bandwidth usage, choose Jpeg HD. It is not possible for a UI3 jpeg stream to get delayed unless it is frozen and not updating at all.
Otherwise if you want to absolutely eliminate delay and don't mind having a low frame rate and higher bandwidth usage, choose Jpeg HD. It is not possible for a UI3 jpeg stream to get delayed unless it is frozen and not updating at all.
Yes.
First, if your settings don't stay between browser reloads, then something is interfering with your ability to save Local Storage data. Typically this will be from instructing the browser to automatically clear cookies periodically or whenever you close a window.
If what you want is to change the default settings of UI3 so that every browser that connects to it gets your custom settings, then look at this help file page, specifically under the "Quick Start" heading. The gist of it is you can download a
First, if your settings don't stay between browser reloads, then something is interfering with your ability to save Local Storage data. Typically this will be from instructing the browser to automatically clear cookies periodically or whenever you close a window.
If what you want is to change the default settings of UI3 so that every browser that connects to it gets your custom settings, then look at this help file page, specifically under the "Quick Start" heading. The gist of it is you can download a
ui3-local-overrides.js file and put it in a certain place within your Blue Iris installation, and that file will get delivered when you load UI3 and it will force the settings within to replace the defaults that UI3 ships with.Thank you, this is what I was looking for. if there's an update to those options from you, such as a new feature. How is that handled when using the overrides file?
It is a bit complex. When you download a local overrides file from the link at the bottom of UI Settings, that file contains a snapshot of all your current settings and their values. Each setting has a unique name, and if I ever delete the setting from UI3 in the future, then the part of the local overrides file that overrides that setting becomes non-functional. If I add a new feature, it probably uses a new setting which your local overrides file won't interfere with because that setting didn't exist at the time when you created the file. If I need to change the way a particular setting works (which is unusual but it does happen sometimes), I delete that setting and create a new one with a different name, and add some code to migrate people's previous preference into the new setting. One specific example is when I added the "Automatic" choice for the H.264 Player setting. I deleted the old setting, added a new one to replace it, and added code to migrate everyone who previously had "HTML5" selected so they instead had "Automatic" selected. Old copies of
ui3-local-overrides.js all referred to the old setting name which does not exist anymore, so they don't cause unwanted interference.I am having issues with PIPELINE_ERROR_DECODE: video decoder reinitialization failed: MEDIA_ERR_DECODE on several cameras when using D2W.
I'm running 225 on 5.6.53, but problem has occurred since 221.
This is occurring on multiple Fire 10 tablets (latest version) as well as older 8th gens. Happens on Chrome/Brave or the default Silk browser.
Two cameras that are having this issue have the following video config settings:
If I skip D2W, no issues. No problem with composite/group images either. When I use the 1MP profile and switch the D2W from "inherit" to "yes" I get the black screen and error on these two cameras. Other cameras (same make/model) don't have the issue despite also being D2W streams. Interestingly, if I drop the profile to 480p, with d2w enabled, I don't get the error, but the stream is 4:3 and poor quality (presumably I'm getting the sub-stream feed).
Any idea what could be causing this error or how to avoid it? I'll play a bit with the main video settings to see if I can find a combination that won't throw an error.
ETA: I dropped the resolution to 1920x1080 on both cameras, and the problem resolved on d2w streaming on the main profile on all devices. Is there perhaps a resolution limit with BI/UI3 D2W?
I'm running 225 on 5.6.53, but problem has occurred since 221.
This is occurring on multiple Fire 10 tablets (latest version) as well as older 8th gens. Happens on Chrome/Brave or the default Silk browser.
Two cameras that are having this issue have the following video config settings:
If I skip D2W, no issues. No problem with composite/group images either. When I use the 1MP profile and switch the D2W from "inherit" to "yes" I get the black screen and error on these two cameras. Other cameras (same make/model) don't have the issue despite also being D2W streams. Interestingly, if I drop the profile to 480p, with d2w enabled, I don't get the error, but the stream is 4:3 and poor quality (presumably I'm getting the sub-stream feed).
Any idea what could be causing this error or how to avoid it? I'll play a bit with the main video settings to see if I can find a combination that won't throw an error.
ETA: I dropped the resolution to 1920x1080 on both cameras, and the problem resolved on d2w streaming on the main profile on all devices. Is there perhaps a resolution limit with BI/UI3 D2W?
Last edited:
Your encoder settings look fine.
I agree, since UI3 still sends all the other encoding parameters in case the camera is not compatible with direct-to-wire, Blue Iris would be using the resolution arguments as a hint to indicate that the sub stream is "good enough".
It is curious that changing the resolution would make it work. Because nope, Blue Iris and UI3 have no such limit, in fact I just opened a 2688x1520 cam streaming H.264 via direct to wire right now and it is fine for me.
Any limit imposed by the web browser, OS, video driver, etc would also affect normal non-direct-to-wire streams too. So my best guess is the cameras are doing something unusual with the H.264 frames, and UI3's HTML5 player is not handling it properly. Whether the fault is in UI3's code or elsewhere, I could not say. Unfortunately the inner workings of H.264 are way over my head so I likely would not be able to figure out a fix even if you were to provide remote access for me to reproduce the issue. All I can say is you might try other H.264 encoding options if your cameras have them (like H.264H) because those might subtly affect the encode in a way that mysteriously works better. But that is really a long shot because plain "H.264" should be as basic and as widely-supported as it can get.
There's a strong chance the JavaScript H.264 player would work with those cams at native resolution if you switched to that in UI3's settings. It is less efficient but usually behaves more predictably than the HTML5 player. Or if you happen to have an HTTPS reverse proxy server available to access Blue Iris with, then you would be able to try the WebCodecs player as a third option that would likely be more efficient than JavaScript. The browser vendors decided to prevent access to WebCodecs except from a secure context. Which is maddening but completely out of my hands
I agree, since UI3 still sends all the other encoding parameters in case the camera is not compatible with direct-to-wire, Blue Iris would be using the resolution arguments as a hint to indicate that the sub stream is "good enough".
It is curious that changing the resolution would make it work. Because nope, Blue Iris and UI3 have no such limit, in fact I just opened a 2688x1520 cam streaming H.264 via direct to wire right now and it is fine for me.
Any limit imposed by the web browser, OS, video driver, etc would also affect normal non-direct-to-wire streams too. So my best guess is the cameras are doing something unusual with the H.264 frames, and UI3's HTML5 player is not handling it properly. Whether the fault is in UI3's code or elsewhere, I could not say. Unfortunately the inner workings of H.264 are way over my head so I likely would not be able to figure out a fix even if you were to provide remote access for me to reproduce the issue. All I can say is you might try other H.264 encoding options if your cameras have them (like H.264H) because those might subtly affect the encode in a way that mysteriously works better. But that is really a long shot because plain "H.264" should be as basic and as widely-supported as it can get.
There's a strong chance the JavaScript H.264 player would work with those cams at native resolution if you switched to that in UI3's settings. It is less efficient but usually behaves more predictably than the HTML5 player. Or if you happen to have an HTTPS reverse proxy server available to access Blue Iris with, then you would be able to try the WebCodecs player as a third option that would likely be more efficient than JavaScript. The browser vendors decided to prevent access to WebCodecs except from a secure context. Which is maddening but completely out of my hands
Your encoder settings look fine.
I agree, since UI3 still sends all the other encoding parameters in case the camera is not compatible with direct-to-wire, Blue Iris would be using the resolution arguments as a hint to indicate that the sub stream is "good enough".
It is curious that changing the resolution would make it work. Because nope, Blue Iris and UI3 have no such limit, in fact I just opened a 2688x1520 cam streaming H.264 via direct to wire right now and it is fine for me.
Any limit imposed by the web browser, OS, video driver, etc would also affect normal non-direct-to-wire streams too. So my best guess is the cameras are doing something unusual with the H.264 frames, and UI3's HTML5 player is not handling it properly. Whether the fault is in UI3's code or elsewhere, I could not say. Unfortunately the inner workings of H.264 are way over my head so I likely would not be able to figure out a fix even if you were to provide remote access for me to reproduce the issue. All I can say is you might try other H.264 encoding options if your cameras have them (like H.264H) because those might subtly affect the encode in a way that mysteriously works better. But that is really a long shot because plain "H.264" should be as basic and as widely-supported as it can get.
There's a strong chance the JavaScript H.264 player would work with those cams at native resolution if you switched to that in UI3's settings. It is less efficient but usually behaves more predictably than the HTML5 player. Or if you happen to have an HTTPS reverse proxy server available to access Blue Iris with, then you would be able to try the WebCodecs player as a third option that would likely be more efficient than JavaScript. The browser vendors decided to prevent access to WebCodecs except from a secure context. Which is maddening but completely out of my hands
I swear, you must not sleep! It works fine on my PC at the higher resolutions with D2W on Brave/Chrome/Edge. So I'm sure it's a limitation of the Fire tablets. I have tried the javascript player does work, but at a much reduced frame rate - maybe 5 FPS. Again, I assume that's because of hardware limits on the tablet. Going the proxy server route is above my paygrade, and I'm happy to just drop the resolution of the cameras down to 1920x1080 if everything plays nicer with that.
I was just hoping there was a quick solution that would preserve the higher resolution. In my use case scenario, max resolution is a nice to have, not a must have.
Well if you don't want to stop using direct-to-wire.... For any camera that supports a 1080p sub stream you might consider setting that up as a copy of the camera in Blue Iris so you can open it with direct-to-wire. Of course you'd also want to use "Limit decoding" on that copy so it wouldn't use much CPU. A bunch of CPU overhead would defeat the purpose of direct-to-wire.
I personally kind of dislike direct-to-wire. But there is no denying its utility for an always-on display if you have that display showing a single camera all the time. If it is only infrequently streaming a single camera, then I'd just leave D2W off and not have to deal with the compatibility issues, the delayed streaming loading, etc.