Blue Iris UI3

@bp2008
Hey aside from the issue earlier I've been having to stay with the version 5.3.7.13 since there is a feature that was remove in the newer version.
On UI3 with the version 5.3.7.13 when you click the delete clip it takes you to the next clip automatically and you can click the delete button again, on newer version once you click the delete button it jumps back to all the cameras feeds, and you have to click the next clip and then click the delete button again each time.

Can this feature be re-added again for next updates?

Thanks.

The behavior you describe from BI 5.3.7.13 is how UI3 currently operates. I'm not sure but maybe there was a bug in some versions between now and then.

When you delete one clip, the next clip is automatically opened (unless there is no "next clip"). There is a setting which affects this. "Clip Review Order/Direction". The default order is "Oldest First". If you want, you can change it to "Newest First" so that UI3 will consider the "next clip" to be lower in the list, a.k.a. older in time. Perhaps this is what you want.

1637891115514.png
 
The behavior you describe from BI 5.3.7.13 is how UI3 currently operates. I'm not sure but maybe there was a bug in some versions between now and then.

When you delete one clip, the next clip is automatically opened (unless there is no "next clip"). There is a setting which affects this. "Clip Review Order/Direction". The default order is "Oldest First". If you want, you can change it to "Newest First" so that UI3 will consider the "next clip" to be lower in the list, a.k.a. older in time. Perhaps this is what you want.

View attachment 109758
Thanks, changed the order and is working as I wanted thank you.
 
UI3 is great. I only have one issue. I can't make it default to Javascript. If I change it to Javascript from HTML5, it just goes back to HTML5 every time I open UI3 again. I saw some reference to changing defaults within .js settings, but I can't seem to find any of this.

EDIT: Tried moving ui3-local-overrides.js to the www folder of Blue Iris to no avail.

AHA!!: I forgot to rename the .txt file to .js. Now it works. I also changed the timeout to "0" so it stays on.
 
Last edited:
If your settings don't stick without a local overrides file, it probably means the cookies and local storage are being cleared regularly by something.
 
What I'm saying is the local overrides file is not normally necessary. Something is unusual about your browser configuration if the settings (including choice of H.264 player) are not sticking between sessions.
 
  • Like
Reactions: OBXJeepGuy
@bp2008 when a camera is triggered and DS canceled the alert the image of the the trigger stays in the Alerts view. UI3 does not automatically clear the canceled trigger from the Alerts list. Is this something you can fix?

Thanks
Mike
 
@bp2008 when a camera is triggered and DS canceled the alert the image of the the trigger stays in the Alerts view. UI3 does not automatically clear the canceled trigger from the Alerts list. Is this something you can fix?

Thanks
Mike

No, that is out of my hands. If you want only the alerts that are not canceled, you probably should be choosing the "Confirmed alerts" filter.

1638039931047.png
 
  • Like
Reactions: MikeLud1
So I opened an issue with the team that created the WebCodecs API, asking them to remove the HTTPS requirement. But I am worried they will not care about a bunch of lunatics that want to use unencrypted HTTP
bp2008,

The WebCodecs API team has assigned someone to work on removing the HTTPS requirement, see below.

1638244570101.png
 
I noticed that the other day. More likely, it just means that person was assigned to deal with the issue, whichever way it goes.

I really don't think Google cares to accommodate us wackos who try to host our own web servers separate from the global internet. I'd be happy to be proven wrong. Heck I would even accept it if there was an easy way to just add a permanent exception for a self-signed HTTPS certificate. But only Firefox has that.
 
Is there any way to make UI3 play alert sounds only for DS confirmed alerts instead of trigger and/or motion?
 
I'm finding an inconsistency in the 'real time stamp' being displayed on the scrub bar when I move the scrubber on one clip vs another. Same camera, just different clips on the same day:

1638716730775.png

Sometimes it'll show the actual timestamp for the interval, other times it just shows the clip elapsed time.

Whether the clip is actually playing or paused when scrubbing makes no difference. Is this something that I've misconfigured?

ETA:

Actually, I just found a common denominator. It the timestamp appears to be missing only on the very first clip of each day (clip that starts at midnight). All the rest of the clips (I have it set to 8 hours, so 4 clips per day) have the timestamp.

ETA2:

Well, the missing timestamp on that camera is specific to the first 8 hour clip of the day, but on some cameras it's completely missing, while others it disappears on random clips...
 
Last edited:
@erkme73

UI3 only shows the real world timestamp if the length of the video file matches the duration that Blue Iris reported for the clip. This condition exists because a common configuration of BI (the default configuration, actually) is to combine multiple motion-triggered recordings into one clip, causing the real world timestamps to be absolutely unpredictable for any given location on the seek bar. The intent is to only show these timestamps when they are guaranteed to be accurate within a few seconds.

Assuming you are recording continuously, this should not have been a problem, so lets see if we can figure out what happened.

I see both your clips you screenshotted are less than 8 hours in length. This suggests those clips were still open for recording. I could see UI3 getting out of sync in this case and thinking it needs to suppress the real world timestamp when it really doesn't need to. Does the timestamp appear reliably for older clips?

It would be helpful if you went through several clips and noted 3 things:
1. Duration shown in the clip list.
2. Duration shown in the seek bar after opening the clip.
3. Whether or not the real-world timestamp is appearing.

If the #1 and #2 values are very far apart, then the real-world timestamp is supposed to disappear.
 
Normally, I just watch the time stamp of the camera. That's the critical time to know since it's consistent to every camera assuming you're using some form of NTP service.
 
@erkme73

UI3 only shows the real world timestamp if the length of the video file matches the duration that Blue Iris reported for the clip. This condition exists because a common configuration of BI (the default configuration, actually) is to combine multiple motion-triggered recordings into one clip, causing the real world timestamps to be absolutely unpredictable for any given location on the seek bar. The intent is to only show these timestamps when they are guaranteed to be accurate within a few seconds.

Assuming you are recording continuously, this should not have been a problem, so lets see if we can figure out what happened.

I see both your clips you screenshotted are less than 8 hours in length. This suggests those clips were still open for recording. I could see UI3 getting out of sync in this case and thinking it needs to suppress the real world timestamp when it really doesn't need to. Does the timestamp appear reliably for older clips?

It would be helpful if you went through several clips and noted 3 things:
1. Duration shown in the clip list.
2. Duration shown in the seek bar after opening the clip.
3. Whether or not the real-world timestamp is appearing.

If the #1 and #2 values are very far apart, then the real-world timestamp is supposed to disappear.

I will verify and let you know shortly. Thanks for quick reply.



Normally, I just watch the time stamp of the camera. That's the critical time to know since it's consistent to every camera assuming you're using some form of NTP service.


I don't use the cameras' internal timestamp. I prefer the more uniform overlay from bi, but with 60 cameras leaving the overlay on playback tends to result in choppy playback. I leave them off unless I'm exporting. That's why having the scrubber show time is so nice when it works.
 
The BI overlay is an inserted video artifact that makes the video potentially useless as evidence in court. I'd rather have it in the base video coming from the camera. Setting up a local NTP server isn't hard at all, heck even I managed to get it working.
 
The BI overlay is an inserted video artifact that makes the video potentially useless as evidence in court. I'd rather have it in the base video coming from the camera. Setting up a local NTP server isn't hard at all, heck even I managed to get it working.

I hate to come across as lazy (because I am), but do you have a good source for setting up a local NTP server? That honestly was one of the concerns. My cameras are all on a non-WAN subnet.