Blue Iris UI3
- Thread starter bp2008
- Start date
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.
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
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.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 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.
Oh, also,
I thought I mentioned that in the earlier reply but I guess I lost that sentence somewhere.
Direct-to-wire has no effect on group streams, since those can only be created the hard way by Blue Iris, not cheaply repackaged from the cameras directly.
I thought I mentioned that in the earlier reply but I guess I lost that sentence somewhere.
I knew that. I was only relaying it as a data point to underscore that it was truly only when switching to D2W that was causing the error.
I suppose I could leave the higher resolution and use h.265, and keep just those cameras excluded from D2W, but then the view won't be smooth. I'm good with 1080p...
Everything has been humming along since reducing the resolutions. No more crashes at all on any of the tablets. So grateful!
But I have another question/request...
Currently I get push notifications for external triggers on an IR beam sensor at my gate. While BI records on motion, it only pushes an alert when the beam is broken. I did this by setting the "on alert" function (under alerts tab on my gate camera) to send a text to my cell (which sometimes comes in HOURS late - thanks Verizon), a push to the official BI app, and an email. I'd love to be able to have my tablet(s) alert on UI3 the same way when the gate camera is triggered by the IR beam.
I've played with the "event-trigger sounds" but have only had limited success.
For example, when I turn on "camera alerting" to doorbell, for example, it does make that sound when the beam is broken. However, it also seems to make the sound with motion triggering - even though none of my other notification pathways (BI app push, text, or email) trigger. UI3 will only make the alert sound if that specific camera is in single-camera display (i.e. not in a group view).
So, my questions are as follows:
1) Is there a way to have UI3 alert in the same manner and scheme as the other BI notification pathways?
2) is it possible to produce that alert sound in UI3 regardless of which camera(s) is/are being displayed?
I realize UI3 can only respect the triggers if it's open and in focus. However, my tables are single-purpose, and stay on 24/7 on UI3.
I have "gifted" an extra tablet to my in-laws who live in a home that shares the same gate - so installing the BI app on that tablet solely for this single notification pathway is not ideal.
ETA: I just sent an email to Ken to see if there isn't a way for him to add "push notification to UI3 client" under the camera properties/alerts tab/on-alert module.
But I have another question/request...
Currently I get push notifications for external triggers on an IR beam sensor at my gate. While BI records on motion, it only pushes an alert when the beam is broken. I did this by setting the "on alert" function (under alerts tab on my gate camera) to send a text to my cell (which sometimes comes in HOURS late - thanks Verizon), a push to the official BI app, and an email. I'd love to be able to have my tablet(s) alert on UI3 the same way when the gate camera is triggered by the IR beam.
I've played with the "event-trigger sounds" but have only had limited success.
For example, when I turn on "camera alerting" to doorbell, for example, it does make that sound when the beam is broken. However, it also seems to make the sound with motion triggering - even though none of my other notification pathways (BI app push, text, or email) trigger. UI3 will only make the alert sound if that specific camera is in single-camera display (i.e. not in a group view).
So, my questions are as follows:
1) Is there a way to have UI3 alert in the same manner and scheme as the other BI notification pathways?
2) is it possible to produce that alert sound in UI3 regardless of which camera(s) is/are being displayed?
I realize UI3 can only respect the triggers if it's open and in focus. However, my tables are single-purpose, and stay on 24/7 on UI3.
I have "gifted" an extra tablet to my in-laws who live in a home that shares the same gate - so installing the BI app on that tablet solely for this single notification pathway is not ideal.
ETA: I just sent an email to Ken to see if there isn't a way for him to add "push notification to UI3 client" under the camera properties/alerts tab/on-alert module.
Last edited:
Not entirely sure what you're asking. I believe the "Camera Alerting" sound is simply played when any of the visible cameras reports that it is alerting.
Technically yes, but I think I would have to add that as an option. I think I probably implemented it so that it only paid attention to the status changes of cameras that are visible on screen at the time. Edit: Yes, I confirm that is how it is right now. Sounds play for visible cameras only.
Heh. I honestly don't see that happening. Implementing a data channel for Blue Iris to send notifications to UI3 would be a fair amount of work for both of us, and it would force the web browser to maintain a continuous connection to the BI server which has a small amount of overhead data cost.
Last edited:
Plus, it would undercut the only remaining reason to have the BI phone app. It is literally the only reason I still have it on my phones.
For anyone following along, further discussion with @erkme73 has led to UI3-226 which allows UI3 to be commanded to play audio or text-to-speech via MQTT command.
Although Blue Iris doesn't provide its own MQTT broker (a.k.a. server), Blue Iris does have an MQTT client. So if you have an MQTT broker, you could connect both Blue Iris and some UI3 instance(s) to the MQTT broker, and have specific actions in Blue Iris cause MQTT messages to be sent to UI3 to play sounds.
Although Blue Iris doesn't provide its own MQTT broker (a.k.a. server), Blue Iris does have an MQTT client. So if you have an MQTT broker, you could connect both Blue Iris and some UI3 instance(s) to the MQTT broker, and have specific actions in Blue Iris cause MQTT messages to be sent to UI3 to play sounds.
This is absolutely wonderful for those with Home Assistant which has an MQTT broker. Now I can use HA to take BI messages and send them to any of my open UI3 instances to play sounds... The potential here is unlimited. Thank you!!
looney2ns
IPCT Contributor
Brian needs some pizza!
www.paypal.me
Pay Brian Pearce using PayPal.Me
Go to paypal.me/bp2008 and type in the amount. Since it’s PayPal, it's easy and secure. Don’t have a PayPal account? No worries.
www.paypal.me
That's funny - I PM'ed him asking for that link. You beat him to it. Need to find another form of payment. I've closed my 23 year old Paypal account after they decided to punish/fine people for wrong-think.Brian needs some pizza!
Pay Brian Pearce using PayPal.Me
Go to paypal.me/bp2008 and type in the amount. Since it’s PayPal, it's easy and secure. Don’t have a PayPal account? No worries.
LOL I also accept amazon gift cards. As much as I order from there it is as good as cash.
@erkme73 Just in case you did not know, you can install MPD (Music Player Daemon) on any number of different devices.
Then, you can tell Home Assistant that a MPD is available via configuration.xml. Here is example of 2 devices with MPD:
Code:
media_player:
- platform: mpd
host: 192.168.11.241
name: SurfacePro MPD
- platform: mpd
host: 192.168.11.211
name: Optiplex MPDI've been doing this before UI3-226. The benefit with the above approach is that UI3 does not need to be running on your device for you to send audio or TTS announcement.
Side note: If your device is Windows, you can install this Introduction - HASS.Agent (which can act as a media player as well as do many other things)
NOW, what would be net new with UI3 is the ability to tell it to switch to a different group or cam, or switch tabs, remotely via MQTT msg.
Still, any improvements by @bp2008 is greatly appreciated.
Last edited:
@actran that is some good info about Music Player Daemon. If that works well on Android, it might be better than UI3 even if UI3 is always running, simply because it will never require user input after the page load to allow audio to play.
Basic remote controls via MQTT were added months ago. Not the ability to switch tabs though. I don't think that would actually offer any value. More valuable would be the ability to load a clip or a timeline position, but I have trouble thinking of how that would be useful to automate.
Basic remote controls via MQTT were added months ago. Not the ability to switch tabs though. I don't think that would actually offer any value. More valuable would be the ability to load a clip or a timeline position, but I have trouble thinking of how that would be useful to automate.
Last edited: