Blue Iris UI3

Your Streaming 0 profile looks fine since UI3 is being allowed to override settings. All of UI3's default profiles override the resolution and bit rate so the 4K one should look basically pristine.

For UI3, bandwidth issues will not cause low quality, it will just cause bad video delay.

It absolutely is supposed to switch to main stream and look almost exactly like the original source video after you maximize a camera (the same as happens when you maximize a camera in the local console of Blue Iris).

On a multi-camera group view it will be all sub streams all the time though.
 
  • Like
Reactions: looney2ns and CJ133
Your Streaming 0 profile looks fine since UI3 is being allowed to override settings. All of UI3's default profiles override the resolution and bit rate so the 4K one should look basically pristine.

For UI3, bandwidth issues will not cause low quality, it will just cause bad video delay.

It absolutely is supposed to switch to main stream and look almost exactly like the original source video after you maximize a camera (the same as happens when you maximize a camera in the local console of Blue Iris).

On a multi-camera group view it will be all sub streams all the time though.

I think that's the problem because when I go full screen on any of the cameras the quality never goes over to main, it just stays looking bad.
On the pc running the cameras you can see it switch over to main and it goes from the way my UI3 looks on my phone to fantastic.
 
@CJ133 Can you take a screenshot of some of your cameras' encoding settings in their web interfaces? Where the main and sub stream resolution and bit rates and stuff is configured?


Here's 3 out of 8.
I have a mixture of 2mp and 4mp cameras so I gave you my two important 4mp and one of the 2mp.
The rest should match these.

Capture1.PNGCapture2.PNGCapture3.PNG
 
Seeing this error message using IOS Brave in UI3 running latest BI stable. Login will occur and video will playback with red error box overlay stays on right side of screen in UI3. Brave on Android works fine.
 

Attachments

  • IMG_0046.png
    IMG_0046.png
    1.7 MB · Views: 0
  • IMG_0047.png
    IMG_0047.png
    578.1 KB · Views: 0
Here's 3 out of 8.
I have a mixture of 2mp and 4mp cameras so I gave you my two important 4mp and one of the 2mp.
The rest should match these.

View attachment 215862View attachment 215863View attachment 215864

Everything looks fine there too. I was wondering if it might be Smart Codec or one of the other poorly supported encoding options but you aren't using anything that normally causes issues for Blue Iris.

Here are a couple more ideas:
1. You could try removing the sub stream path from one of the cameras, and see if it plays okay in UI3 live view (I assume it will play fine and look good). Then re-add the sub stream path to that camera and see if the problem comes back. Blue Iris does some stuff with the anamorphic scaling option when you do this, and it could possibly be messed up in its current state.
2. If you have hardware accelerated decoding enabled globally or for any of your cameras in BI, try turning that off.
3. Does Blue Iris's log file show any suspicious errors that could be related to video processing in some way?
4. Is your Blue Iris support plan still active? You might try updating to the latest release.
 
  • Like
Reactions: CJ133
Seeing this error message using IOS Brave in UI3 running latest BI stable. Login will occur and video will playback with red error box overlay stays on right side of screen in UI3. Brave on Android works fine.
That is UI3's global error handler catching an error in a script that does not belong to UI3. It could be a script injected by a browser extension or by the web browser itself. Either way, I have a mechanism in place in UI3 for ignoring specific error messages in situations just like this and I'll add that message to the list.
 
  • Like
Reactions: biggen
Viewing an alert is easy to do by accident.
Hello,

Ok that all makes sense. Thanks for look into this. To get around the BI limitations, would it be possible to create an mqtt function similar to the audio notice that's in UI3, only instead of playing audio, use toast style pop-ups. This would give one very granular control over when an alert is made noticeable in the UI. One would pass the camera name (or anything I suppose) from BI in the mqtt message to UI3 and this message would then display on screen until one closed it.
 
Hello,

Ok that all makes sense. Thanks for look into this. To get around the BI limitations, would it be possible to create an mqtt function similar to the audio notice that's in UI3, only instead of playing audio, use toast style pop-ups. This would give one very granular control over when an alert is made noticeable in the UI. One would pass the camera name (or anything I suppose) from BI in the mqtt message to UI3 and this message would then display on screen until one closed it.
I like that idea, and yes of course that is possible. I've added this to my issue tracker: Add MQTT command to display a toast message · Issue #195 · bp2008/ui3

Can you think of any other features this should have besides what I wrote in the issue? I have not decided yet if I should try to accept all options within the MQTT topic string or if I should just specify that you need to publish a payload/message in JSON format with any desired options in it.

So it could be specified like this, keeping the topic string nice and simple but making the message complex:

ui3/instance_id/toast/{toast_id} = JSON_OBJECT

Example usage:
ui3/instance_id/toast/frontdoor_alert = { "msg": "Alert at Front Door", "type": "info", "timeout": -1, "click": "alerts:123456789" }

This would display an "info" toast (blue background) that has the message "Alert at Front Door" and does not expire. When clicked, this would open the Clips tab filtered to "Alerts", maximize whichever camera was associated with alert ID 123456789, start playing that alert, and close the toast message. Because timeout is specified as a negative number, I would give the toast a close button (X in the top right corner) that could dismiss the toast without activating its click event. Publishing another string to the same topic (ui3/instance_id/toast/frontdoor_alert) would cause the toast to be replaced rather than adding another toast.

Or I could code it to accept all the arguments in the topic string, making the topic string complex but keeping the message simple:

ui3/instance_id/toast/{arguments} = MESSAGE

Example usage:
ui3/instance_id/toast/id=frontdoor_alert&type=info&timeout=-1&click=alert:123456789 = Alert at Front Door

This would have exactly equivalent behavior to the previous example. Do you know which of these methods would be easier to integrate with third-party stuff like home assistant?
 
"click": "alerts:123456789"
I like the first format as it follows json style and is clearer to me. HomeAssistant runs on JSON so it's compatible, but one could parse either format and extract the complete payload in the message. I also like the timeout function as one could set this to say 600 seconds to limit screen time for notices if need be. I'm not sure how you would pass the alert number as although BI does offer the "&ALERT_DB" macro, I've never tried to use these macros in an mqtt message. If someone has some experience with BlueIris macros in mqtt messages please weigh in. The alert launch function from this alert indexId might take some de-bugging to get right. I also like the "type" field as it suggests that you can choose different levels of alerts from info to warning to critical. I imagine each alert type would take a distinct color.
 
  • Like
Reactions: bp2008
Everything looks fine there too. I was wondering if it might be Smart Codec or one of the other poorly supported encoding options but you aren't using anything that normally causes issues for Blue Iris.

Here are a couple more ideas:
1. You could try removing the sub stream path from one of the cameras, and see if it plays okay in UI3 live view (I assume it will play fine and look good). Then re-add the sub stream path to that camera and see if the problem comes back. Blue Iris does some stuff with the anamorphic scaling option when you do this, and it could possibly be messed up in its current state.
2. If you have hardware accelerated decoding enabled globally or for any of your cameras in BI, try turning that off.
3. Does Blue Iris's log file show any suspicious errors that could be related to video processing in some way?
4. Is your Blue Iris support plan still active? You might try updating to the latest release.
I just had time to do some tests.
Removing the substream does solve the issue and it looks pretty good, however the problem returns when I put the substream back.
It appears to be doing this on all 8 cameras.

I did find one with the smart codec enabled and I turned it off but it didn't effect it.
I wasn't able to find any log file under the log folder for Blue Iris.

All hardware decoding is set to "default" but I switched them all to "no" and it didn't change.

No support plan yet, but I plan on renewing soon. I usually do every once in a while.
 
I just had time to do some tests.
Removing the substream does solve the issue and it looks pretty good, however the problem returns when I put the substream back.
It appears to be doing this on all 8 cameras.

I did find one with the smart codec enabled and I turned it off but it didn't effect it.
I wasn't able to find any log file under the log folder for Blue Iris.

All hardware decoding is set to "default" but I switched them all to "no" and it didn't change.

No support plan yet, but I plan on renewing soon. I usually do every once in a while.

Look in Blue Iris's status window. It is the icon at the top that looks like a squiggly arrow pointing up and to the right. There you will find the "Log" tab and a checkbox at the bottom that lets it be saved to a file. Otherwise you just have the log messages since the last time Blue Iris restarted.


Hmm. You said originally you think this started when you changed the cameras from H.265 to H.264. Have you tried setting one cam back to H.265 on both main and sub streams to see if that brings back normal functionality? (right click and restart the camera instance in Blue Iris after you change video codecs like that, otherwise the video may freeze for a while) I assume you must have tried that already and it didn't work right?

I still can't figure out a reasonable cause for this issue. The fact the main stream will be sent to UI3 just fine when the sub stream is not available makes me think the problem probably lies in whatever code handles transitioning from sub stream to main stream. But I've never heard of this issue before so I can't imagine what else could be different about your system to trigger this behavior.

At this point I can only suggest you try installing one of Blue Iris's other updates that was released before the end of your support plan, in the hopes that the bug isn't present in another version. Your support end date should be printed in Blue Iris Settings > About tab in the same section where you can check for updates.
 
Look in Blue Iris's status window. It is the icon at the top that looks like a squiggly arrow pointing up and to the right. There you will find the "Log" tab and a checkbox at the bottom that lets it be saved to a file. Otherwise you just have the log messages since the last time Blue Iris restarted.


Hmm. You said originally you think this started when you changed the cameras from H.265 to H.264. Have you tried setting one cam back to H.265 on both main and sub streams to see if that brings back normal functionality? (right click and restart the camera instance in Blue Iris after you change video codecs like that, otherwise the video may freeze for a while) I assume you must have tried that already and it didn't work right?

I still can't figure out a reasonable cause for this issue. The fact the main stream will be sent to UI3 just fine when the sub stream is not available makes me think the problem probably lies in whatever code handles transitioning from sub stream to main stream. But I've never heard of this issue before so I can't imagine what else could be different about your system to trigger this behavior.

At this point I can only suggest you try installing one of Blue Iris's other updates that was released before the end of your support plan, in the hopes that the bug isn't present in another version. Your support end date should be printed in Blue Iris Settings > About tab in the same section where you can check for updates.
I just updated to 5.9.9.27 because it was overdue anyway.
Nothing useful under the log, though I noticed it detected Intel graphics.
I don't know if it would help or not, but these are the settings I'm using under the cameras. They're all Dahua from Andy.

Capture4.PNG
 
I just updated to 5.9.9.27 because it was overdue anyway.
Nothing useful under the log, though I noticed it detected Intel graphics.
I don't know if it would help or not, but these are the settings I'm using under the cameras. They're all Dahua from Andy.

View attachment 215976
That config looks fine for Dahua cameras too. If changing back to H.265 fixes the issue it might be worth just sticking with that. Otherwise it sounds like your support plan is actually active still so contacting Blue Iris support would be the next step I think..