Ssayer
BIT Beta Team
Forget the weather, put a cam on Pelosi and see what stocks SHE is buying tomorrow... 
Blue Iris UI3
- Thread starter bp2008
- Start date
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:
Oopsie. I'll get it fixed. Thanks @erkme73
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.
FWIW, I get these occasionally too:
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?
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.
Well, if it helps any, I've had a single playback camera screen up for most of the day on UI3 - paused. When I clicked the X to go back to live, I got the live camera immediately. I did nothing else, and within a few seconds I got the "player stall" error. It was 1:1 on the zoom, and no input. I suppose it's possible that after sitting for hours on a paused playback clip that it some how lost its bearings?
ETA: I'm not on 204 yet. This is still 203 from last night. I was just commenting that it didn't involve any zooming. I'll jump to 204 and see what happens.
Being paused shouldn't have affected it. But yeah in UI3-203 you only needed to have 5 frames queued and for the video player to simultaneously say it was waiting for more data, and it would trigger the stall detection. UI3-204 added a requirement that the video remain stalled for 2 seconds, and that timer increases by 2 seconds every time it triggers (resets to 2 seconds again if you reload the page). So that should eliminate most of the false alarms.
I do have a bit of a follow up question about the jerky playback/streaming. I am quick to say it's all with the BI machine or network since the playback is rough regardless of client browser or machine hardware. However, when looking at the stats for nerds, I see this:
The playback is mostly smooth, but every second or so, it glitches, pauses/skips and the resumes. As it does this the delayed frames goes from 1 or 2 to about 15. At the same time the player delay bumps up to around 400-500ms. The network delay is staying at or very near 0000ms.
Does the screen grab make you think of anything specific? You'd said something about using another player, but the only options I have are auto/html5/java.
Also, the little blue scrubber line that moves across the stats for nerds box stops moving with every glitch - as do all the variables on the box.
It almost seems like a local issue. Yet, it happens on my PC and phone (android).
BTW, the screenshot above was for html5. When I use java (and reload screen), I get this:
While the player delay is relatively smaller (max was <100ms) the same pausing/hiccuping is happening - where all variables freeze with each glitch.
The playback is mostly smooth, but every second or so, it glitches, pauses/skips and the resumes. As it does this the delayed frames goes from 1 or 2 to about 15. At the same time the player delay bumps up to around 400-500ms. The network delay is staying at or very near 0000ms.
Does the screen grab make you think of anything specific? You'd said something about using another player, but the only options I have are auto/html5/java.
Also, the little blue scrubber line that moves across the stats for nerds box stops moving with every glitch - as do all the variables on the box.
It almost seems like a local issue. Yet, it happens on my PC and phone (android).
BTW, the screenshot above was for html5. When I use java (and reload screen), I get this:
While the player delay is relatively smaller (max was <100ms) the same pausing/hiccuping is happening - where all variables freeze with each glitch.
Wow @erkme73 your screenshots have some weirdness in them.
especially this part: 
and here where there's a cutout: 
If that is only that way in your screenshots then I can chalk it up to buggy screen capture software. But if it draws that way in-person too then I suspect hardware problems on your machine.
Anyway...
Some brief network interruption is seen at a few points in your first screenshot. That is where the network delay steadily rises and the player delay falls at about the same rate (at least until it hits 0); that is because the network isn't receiving frames anymore, but the player is still consuming them. Then suddenly the delayed frames all arrive from the network so network delay shoots back to 0 and player delay jumps up because now the player needs to catch up.
The network delay could be caused by a lot of things, but this particularly makes me suspect two possibilities, one being a buggy proxy server being used (possibly integrated into security software you're running on the clients or on the BI server) and the other possibility, just a badly performing network.
One diagnostic tool you could use is PingTracer which is an app of my own design that can send pings to a network host up to 10 pings per second and graph the response times. I suggest you run that on a client machine, pinging the BI machine at 10 pings per second, and see how the graph looks compared to the Stats for nerds graphs. If the network is performing well, it will be a relatively flat green graph, maybe even just 1 pixel tall because on a LAN the response time should be 0 milliseconds typically. If it is not performing well, you will see lots of spikes, possibly colored yellow or red.
If the network is working well for pings, that points the finger at internet security software or a bad proxy server you might have set up.
especially this part: and here where there's a cutout: If that is only that way in your screenshots then I can chalk it up to buggy screen capture software. But if it draws that way in-person too then I suspect hardware problems on your machine.
Anyway...
Some brief network interruption is seen at a few points in your first screenshot. That is where the network delay steadily rises and the player delay falls at about the same rate (at least until it hits 0); that is because the network isn't receiving frames anymore, but the player is still consuming them. Then suddenly the delayed frames all arrive from the network so network delay shoots back to 0 and player delay jumps up because now the player needs to catch up.
The network delay could be caused by a lot of things, but this particularly makes me suspect two possibilities, one being a buggy proxy server being used (possibly integrated into security software you're running on the clients or on the BI server) and the other possibility, just a badly performing network.
One diagnostic tool you could use is PingTracer which is an app of my own design that can send pings to a network host up to 10 pings per second and graph the response times. I suggest you run that on a client machine, pinging the BI machine at 10 pings per second, and see how the graph looks compared to the Stats for nerds graphs. If the network is performing well, it will be a relatively flat green graph, maybe even just 1 pixel tall because on a LAN the response time should be 0 milliseconds typically. If it is not performing well, you will see lots of spikes, possibly colored yellow or red.
If the network is working well for pings, that points the finger at internet security software or a bad proxy server you might have set up.
Wow, thanks for all the detail explanation. A lot to unpack here. I will dig into your suggestions a bit later this evening when I get some more me time. I quickly ran your ping tracer and got this:
I have no proxy set up, and no antivirus software on either machine (other than what Windows 10 comes with - and I've attempted to neuter that as much as possible). Interestingly, the firewall was up on the BI machine (presumably from an update). So I disabled it and still find the same glitching.
I have no proxy set up, and no antivirus software on either machine (other than what Windows 10 comes with - and I've attempted to neuter that as much as possible). Interestingly, the firewall was up on the BI machine (presumably from an update). So I disabled it and still find the same glitching.