Using the same alert clip of a truck passing by at 6:35:41PM. Using other clips has similar results but the time offset varies.
UI2 Firefox starts 6:35:30 which is good
UI3 Firefox starts at 6:19:18
UI3 Edge starts at 6:35:51
As noted earlier, Alert playback is not finished yet. But this did reveal something I wasn't aware of. I thought that H.264 streaming was starting at the right position but it is obvious now that it is not. I found the way to fix it but it brings along some unwanted side-effects I'll have to work through.
FYI, Edge is capable of streaming H.264 so it does that by default. Firefox can only handle Jpeg streaming for now, which is why it behaves so differently.
Anyway I'll release beta 3 soon and alert playback will be more functional, although when streaming jpegs you will be unable to seek outside the boundaries of the alert, just like in UI2. When streaming H.264 you
will be able to seek outside the boundaries of the alert, just like in the
Blue Iris console and official mobile apps. The final goal is for both streaming methods to let you seek outside the boundaries of the alert because this is how Blue Iris has always done it, but to achieve this it will take cooperation from Ken.
My Blue Iris server hovers at ~50%, 2G out of 8G RAM. There are CPU spikes when I switch streaming mode.
I'm not able to crash Blue Iris every time so I don't know what exact factors is causing it.
Well this isn't good. Ken doesn't like it when Blue Iris crashes because of something the web UI is doing
It used to be fairly easy to do on an overloaded system if you changed clips rapidly.
About how quickly are you changing streaming modes? Once per second? Twice per second? What video is playing at the time? A group? Single camera? Clip?