Blue Iris UI3

[bp2008]

BP2008,

Thanks for the quick turnaround. The new version fixed the errors but when I have an alert it does not Auto-Maximize.

Thanks
Mike

Noted. I will fix soon. Maybe tomorrow.

 

[hikky_b]

I've just updated to 5.5.1.2 / UI3 v172.

All devices running fine except an old iPad. I've cleared all browsing data and restarted the device but still displays the same message. UI3 will not load beyond this.

 

[bp2008]

Ack. I wrote the same problem twice in a single week. I am so embarrassed now. Will be fixed in UI3-174.

 

[MikeLud1]

Ack. I wrote the same problem twice in a single week. I am so embarrassed now. Will be fixed in UI3-174.

I just loaded UI3-174 all back to normal. Thanks again for all your hard work.

Mike

 

[MikeLud1]

I'll see about making it happen! Follow this issue if you want to keep track of when this is completed.

bp2008,

Thanks for working on my enhancement request. I just loaded version 177 which as I understand should complete this enhancement. The clip preview animation works fine but the static image and the alert property is still low-res.

I think you are using the thumbs for the image, if you change to alerts it will use a hi-res image.



Another enhancement request is to add the ability to adjust the speed of the clip preview animation.

Thanks
Mike

 

[bp2008]

@MikeLud1

Version 178

• Removed setting "Preview clips at native resolution" because it didn't work as intended.
• Alerts with a Hi-res JPEG available are now previewed at native resolution in the mouseover popup and in the alert properties dialog.
• Added setting "No preview animation for alerts with Hi-res JPEG" so that deepstack tags can be inspected in mouseover popups without having to disable the preview animations globally.
• Added settings to configure clip preview speed and number of frames:
  

 

[MikeLud1]

@MikeLud1

Version 178

• Removed setting "Preview clips at native resolution" because it didn't work as intended.
• Alerts with a Hi-res JPEG available are now previewed at native resolution in the mouseover popup and in the alert properties dialog.
• Added setting "No preview animation for alerts with Hi-res JPEG" so that deepstack tags can be inspected in mouseover popups without having to disable the preview animations globally.
• Added settings to configure clip preview speed and number of frames:
  

bp2008,

Thanks again for the quick turnaround

Mike

 

[Ssayer]

Ok, I was running Ubunto Stretch on my Pi 3 and for some reason, I quit getting sound when running UI3 in the browser (sound works with everything else in the browser). Knowing that my version of Ubunto was old, I figured I'd just go to the latest Pi version and see if that, alone, would fix the sound. Many hours later (slow slow slow connection) and it was up and running. Yep, sound works.

Now I have a new problem (maybe an older one too, but the last I looked it was ok). When I select a cam to go full frame, it always full frames the wrong cam. I've tried everything I can think with no good results. This works correctly on my three tablets and our computers, so... I must be missing something with Ubunto. Can anyone running linux give me a clue?

 

[DSteiNeuro]

Ok, I was running Ubunto Stretch on my Pi 3 and for some reason, I quit getting sound when running UI3 in the browser (sound works with everything else in the browser). Knowing that my version of Ubunto was old, I figured I'd just go to the latest Pi version and see if that, alone, would fix the sound. Many hours later (slow slow slow connection) and it was up and running. Yep, sound works.

Now I have a new problem (maybe an older one too, but the last I looked it was ok). When I select a cam to go full frame, it always full frames the wrong cam. I've tried everything I can think with no good results. This works correctly on my three tablets and our computers, so... I must be missing something with Ubunto. Can anyone running linux give me a clue?

I had this also on Windows. Not sure exactly what I did to fix it but went back into the BI and reset the group settings

 

[bp2008]

Ok, I was running Ubunto Stretch on my Pi 3 and for some reason, I quit getting sound when running UI3 in the browser (sound works with everything else in the browser). Knowing that my version of Ubunto was old, I figured I'd just go to the latest Pi version and see if that, alone, would fix the sound. Many hours later (slow slow slow connection) and it was up and running. Yep, sound works.

Now I have a new problem (maybe an older one too, but the last I looked it was ok). When I select a cam to go full frame, it always full frames the wrong cam. I've tried everything I can think with no good results. This works correctly on my three tablets and our computers, so... I must be missing something with Ubunto. Can anyone running linux give me a clue?

I guess you were probably using an older UI3 release. UI3-161 added FLAC audio support, enabled by default, but in some browsers it fails to decode and this wasn't handled properly until UI3-169 which should correctly reset your audio codec to old-reliable ulaw.

Also starting with UI3-164, Blue Iris started creating dynamic group layouts that try to fit UI3's browser window, and this introduced a lot of new opportunities for UI3 to be wrong about the locations of the cameras in the group video stream. If the "wrong camera opens" bug is consistent on a particular machine and you have the latest Blue Iris release, I'd like to hear more about it. Possibly you've encountered a bug I am not aware of.

 

[Ssayer]

I'm running the latest BI release (5.5.1.6). I've tried different groups and the only group it consistently gets the correct camera opened is on the group with only two camera. Even the group that has only four camera has the wrong cam opened. The group I normally have running on the Ubunto box has 20 cams on it. It's funny because no matter which cam I attempt to open, it always opens a different one. What info are you looking for? Once again, it's only the PI 3 that has this issue, every other device gets it right...

 

[Ssayer]

Spent the morning upgrading Chromium (default Ubunto browser). Heh, now I only get JPEG, so no sound. BUT, the correct camera opens. It won't let me grab Chrome, don't ask me... So, I'm currently grabbing Firefox (will take a while). We'll see how it goes.

Come on Starlink, pick me!!

 

[Ssayer]

And there it is! Ok, JIK anyone else is/will be going through this with a Raspberry Pi: Old version of Chromium supports sound but cams don't open up properly. New version of Chromium is JPEG only (no sound) but cams open up properly. EVERYTHING works correctly with Firefox.

 

[bp2008]

@Ssayer My best guess is that recent versions of Chromium are simply buggy on the pi. It could reporting mouse coordinates incorrectly, or it could be rendering the video at the wrong scale or wrong position so that is misaligned with the click handling script.

New version of Chromium is JPEG only (no sound) but cams open up properly.

Can you screenshot UI3's "About" window in this Chromium version? Several feature detection failures get reported there, which could reveal what exactly prevents H.264 from being supported.

If you can, also open the dev tools (F12 OR ctrl + shift + i) to the Console tab and reload the page so you capture all the console output, and screenshot that as well.

 

[Ssayer]

Phone shot

 

[bp2008]

Thanks. So webgl is unavailable in your latest chromium release. How unusual.

I wonder if the HTML5 player actually requires webgl or if that requirement only applies to the JavaScript player....

 

[bp2008]

Hey @Ssayer I don't have a convenient device with no webgl support, so if you wouldn't mind a little bit of advanced diagnostics, you can try hacking out the webgl feature check and see if the HTML5 video player still works to play H.264.

First, make sure in UI Settings > Video Player the H.264 player should be set to HTML5. Then open the ui3.js file in your Blue Iris 5/www/ui3 folder and go to about line 283 where it says

function detectWebGLContext()
{
    var canvas = document.createElement("canvas");
    var gl = canvas.getContext("webgl")
        || canvas.getContext("experimental-webgl");
    return gl && gl instanceof WebGLRenderingContext;
}

and just add a line saying return true; at the beginning of that function like this.

function detectWebGLContext()
{
   return true;
    var canvas = document.createElement("canvas");
    var gl = canvas.getContext("webgl")
        || canvas.getContext("experimental-webgl");
    return gl && gl instanceof WebGLRenderingContext;
}

Then CTRL+F5 to hard reload UI3 in chromium (this should override any cached ui3.js file) and see if the H.264 streams like 1080p work again. One way to be sure your change got loaded is to look in the "About" window, where the webgl warning should be gone.

 

[Ssayer]

@bp2008: That fixed it. Just to re-affirm: Newest version of PI Os with newest version of Chromium... Sound working and proper cam opening now with all video streams as options.

Thanks much!

 

[bp2008]

Thanks @Ssayer. To fix this issue properly, I had to dig into several parts of the code which simply treated the JavaScript player preconditions as being preconditions for H.264 playback in general. From UI3-179 onward, this should no longer be a problem for you!

 

[wittaj]

@bp2008 - thanks for all you do for the community! No idea if you get a piece of BI sales or not, but regardless, the stuff you share here are great tools!