The current time at the top is cut off...what time does it read and what is, in fact, the current time when the screenshot was made?
Blue Iris UI3
- Thread starter bp2008
- Start date
Don't remember what time that was, probably right before I posted it, here it is with the time. Not a big deal to me, just posted that it was doing it on one camera here.
What I'm saying is that by what you said in your first post ( "I have one camera that is going into the future") and by what is shown in either image that it's not clear, at least to me, what it is you're saying. Maybe I need another cup of coffee. 
Oh, I see it now.....guess I did need that second cup of coffee. It didn't jump out at me, maybe because I have no cams with a brown color band...or maybe because I'm an old fart. Either way, it seems you're correct.The brown line is one camera and it seems to think it's got recordings out past the blue line which is the current time.
Unless I'm seeing it wrong, which is always a possibility!
Play the video so you can see what the weather will be like tomorrow!
Ssayer
BIT Beta Team
Forget the weather, put a cam on Pelosi and see what stocks SHE is buying tomorrow...
I'll bet it's public park improvement contractors in San Francisco or roadway bridge contractors somewhere in New York.Forget the weather, put a cam on Pelosi and see what stocks SHE is buying tomorrow...
Same thing as MrRobinHood had. Probably a bug in BI.
I'm running into a new issue on 201 and 202. When I click on a recorded clip, the clip begins to play, but the dimmed overlay with the spinning circle doesn't go away. The FPS stays at 0. The video is playing. I've restarted the server, and I see this across several clients and browsers.
If I scrub, the main video will move along to a certain point. Then it'll freeze. Stats for nerds shows it continuing to play, and I can hear the audio stream going in the background.
It's almost like the player doesn't know how play the stream.
Live video works great.
This happens on both Javascript or HTML5.
ETA: This anomaly happens only when using the "clips" tab in UI3... It appears to work fine using the new time line tab. It also works fine on the UI3 server console as well, fwiw.
If I scrub, the main video will move along to a certain point. Then it'll freeze. Stats for nerds shows it continuing to play, and I can hear the audio stream going in the background.
It's almost like the player doesn't know how play the stream.
Live video works great.
This happens on both Javascript or HTML5.
ETA: This anomaly happens only when using the "clips" tab in UI3... It appears to work fine using the new time line tab. It also works fine on the UI3 server console as well, fwiw.
Last edited:
Bug is fixed in UI3-203 @erkme73. Releases · bp2008/ui3
Wow! What took so long?! /s
While I have your ear, here are a few other things that may be a bit off (or operator error):
- When viewing timeline on an indexed/group view, clicking through to individual cameras does not necessarily bring up the camera selected - it may be off by several cameras (this was the case with 200, but I haven't verified on the latest).
- When viewing timeline, the FPS seems to show around 30FPS, even when the actual rate is less. For example, a camera set to 15FPS, will show 15-ish FPS when viewing playback under the clips tab, but will be around 30FPS when playing back via timeline.
- When viewing a group on timeline, and clicking on a single camera brings up the camera in full screen at that moment on the timeline, when clicking on the "clips" tab, should the clip still be at that same moment in time? I can't find a consistent way to pull it off... sometimes it does seem to stay at the same time, and other times, it jumps back to live when clicking on the clips tab.
I thought I had solved all the issues with #1 in UI3-200, but there are a lot of variables involved.
Show UI3's camera labels via CTRL + L and see how they differ from what is on-screen. These labels are aligned with wherever UI3 thinks the cameras are, so it is useful for quickly determining if everything is lined up properly. I need to figure out what condition makes them wrong. e.g. in UI3-199 the layout was wrong if you were streaming a static-layout group at a resolution lower than its native resolution
Ken had Blue Iris encode the timeline video differently from normal. Internally Blue Iris is creating a certain size of drawing surface, drawing video to it, and then encoding that surface at 30 FPS to send out through the web server. So it is expected to be 30 FPS (or up to whatever your system can handle) regardless of what video is shown inside.
That is working as intended (for now). You can transfer your clip viewing timestamp to the timeline tab, but you can't transfer your timeline viewing timestamp to the clips tab (yet; in theory I should be able to pull it off, but it will take some work). So when you say "I can't find a consistent way to pull it off... sometimes it does seem to stay at the same time", that is probably when you start on the clips tab, open a clip, then go to the timeline tab (the clip remains open until you close it or open some other video source) and go back to the clips tab without closing the clip.
That all makes sense - thanks.
A follow up question to the FPS for the timeline. Since I'm seeing 30, if the camera is truly set to 30FPS (and the overly is reporting 30FPS) but the actual stream is bouncing around from 6 to 15, bursty and stroby, does that still indicate a network issue?
I'm getting smooth as silk from each camera's GUI page, but ever since upgrading from 5.5.0.15, my live and playback streams are so choppy they are a challenge to watch. I get the occasional orange clock too. This happens regardless of PC/phone, or browser.
If I roll back to the 0.15 it's much less stroby. I'm seeing the same results if I use the BI android app - so maybe this is a question for Ken...
ETA: FWIW, I get these occasionally too:
A follow up question to the FPS for the timeline. Since I'm seeing 30, if the camera is truly set to 30FPS (and the overly is reporting 30FPS) but the actual stream is bouncing around from 6 to 15, bursty and stroby, does that still indicate a network issue?
I'm getting smooth as silk from each camera's GUI page, but ever since upgrading from 5.5.0.15, my live and playback streams are so choppy they are a challenge to watch. I get the occasional orange clock too. This happens regardless of PC/phone, or browser.
If I roll back to the 0.15 it's much less stroby. I'm seeing the same results if I use the BI android app - so maybe this is a question for Ken...
ETA: FWIW, I get these occasionally too:
@erkme73
Do you still have problems clicking cameras and going to the wrong camera in UI3-200? If so I'd love to figure out why so I can fix it.
Network issues usually cause video delay to grow out of control. If the FPS is too low or unstable but the video is not really delayed, that indicates a problem processing the video (related to CPU, memory, etc).
5.5.0 was the update that introduced dynamic group layouts, which can have higher default resolutions than before (which makes them very expensive to encode). Try the "Edit layout" button here
and right click a camera, go to Frame > Height > 1080p or 720p. That will limit the size of the dynamic group streams which should improve performance. You can also limit the FPS using the gear button next to the "Edit layout" button, that may help keep things more consistent.
Do you still have problems clicking cameras and going to the wrong camera in UI3-200? If so I'd love to figure out why so I can fix it.
Network issues usually cause video delay to grow out of control. If the FPS is too low or unstable but the video is not really delayed, that indicates a problem processing the video (related to CPU, memory, etc).
5.5.0 was the update that introduced dynamic group layouts, which can have higher default resolutions than before (which makes them very expensive to encode). Try the "Edit layout" button here
and right click a camera, go to Frame > Height > 1080p or 720p. That will limit the size of the dynamic group streams which should improve performance. You can also limit the FPS using the gear button next to the "Edit layout" button, that may help keep things more consistent.
Thanks for letting me know. The code may be too aggressive at detecting this still. What was happening when that occurs? Had you just been zooming with the mouse wheel?FWIW, I get these occasionally too:
See, there's a problem I've been having for about a year or longer where zooming in a long distance in UI3 causes Chromium-based browsers to glitch out. In Chrome it freezes the video player when that happens and the only way to recover it is to start a new video stream, and then Chrome will be fine until all Chrome windows are closed and reopened. So I added code to try to detect that exact situation but it is hard because no typical error is thrown.
Using the ctrl-l trick certainly helped to get a good overview. I am not able to find any mismatched timeline group images to their respective individual cameras. So I think you've squashed that bug. I should have tested it on the latest 203 version before asking for clarification, as it does appear you've fixed it.
As for the dynamic layout and the network delays, I'm getting these delays and orange clocks on single camera streams as well - not just the groups. I'll readjust the group layout to a fixed resolution to see if it helps.
FWIW, the CPU is around 60% on the server, with network utilization at 16%. The PC I'm viewing is at 0% utilization while streaming on UI3. So unless I have failing hardware somewhere on the network, I'm at a loss as to the slowdown.
Last edited:
I will have to pay more attention to the circumstances leading up to that error. I've got to homeschool kids for next few hours so I'll have to play a bit later.
Just verified that the frame height was already set pretty low (720). FPS on group view was already set to 5FPS as well. Again the issue is prevalent in single cameras as well - so I don't think it is specific to the group/index views.
I didn't change anything related to layouts in 201-203, but it is possible you were just remembering behavior in 197-199 and did not actually see it broken in 200.
I will adjust the "stall detection" again for version 204, and make it wait a little longer for signs of activity before declaring the video player dead.
720p @ 5fps and single camera views should stream perfectly. If you open "Stats for nerds" it will show you the network delay and the player delay, that is a clue for the source of the problem. Network delay could be anything from the network or Blue Iris or even a camera problem. Player delay is 100% internal to UI3 so if you get a lot of delay there it could be worth changing the H.264 player choice in UI Settings.
Thanks for your help.
I will adjust the "stall detection" again for version 204, and make it wait a little longer for signs of activity before declaring the video player dead.
720p @ 5fps and single camera views should stream perfectly. If you open "Stats for nerds" it will show you the network delay and the player delay, that is a clue for the source of the problem. Network delay could be anything from the network or Blue Iris or even a camera problem. Player delay is 100% internal to UI3 so if you get a lot of delay there it could be worth changing the H.264 player choice in UI Settings.
Thanks for your help.