5.9.9 - January 17, 2025 - More Pre-6.0 feature releases
- Thread starter jaydeel
- Start date
Here's the Help PDF entry for the new push notification option...
I've played with this and it's pretty neat.
Here's how you can use it in a 'Push' action...
UNDER THE HOOD
Here's a screenshot of the tmpfiles.org server's API link.
If you issue a curl command like the following in cmd.exe (or a powershell console)
you will get this response
Opening your browser on API's response URL, shows an output the following screenshot.
I've confirmed that this image remains accessible on the tmpfiles.org server for only 60 minutes.
I've played with this and it's pretty neat.
Here's how you can use it in a 'Push' action...
UNDER THE HOOD
Here's a screenshot of the tmpfiles.org server's API link.
If you issue a curl command like the following in cmd.exe (or a powershell console)
curl -F "file=@C:/temp/test.jpg" https://tmpfiles.org/api/v1/uploadyou will get this response
Opening your browser on API's response URL, shows an output the following screenshot.
I've confirmed that this image remains accessible on the tmpfiles.org server for only 60 minutes.
Regarding the 2nd item in post #1
This new feature sounds like a response to requests like this post.
It has the following detail in the Help PDF...
I've tried testing URLs like the following in a browser, but I'm getting no response.
I'm probably missing something. Perhaps @bp2008 can illuminate?
"... /time/ web server interface now supports MJPEG video for easy browser playback and relative time specification (i.e., 1 minute ago)"
This new feature sounds like a response to requests like this post.
It has the following detail in the Help PDF...
I've tried testing URLs like the following in a browser, but I'm getting no response.
http://192.168.1.3:8600/time/DW1?pos=-10000http://192.168.1.3:8600/time/DW1?mode=mjpg&pos=-10000I'm probably missing something. Perhaps @bp2008 can illuminate?
Last edited:
Looks like you just take any valid timeline jpeg URL and change the word "jpeg" to "mjpeg". It might not be documented very well in Blue Iris's help file. Ken and I worked out the original details of remote timeline streaming together via email years ago so I didn't build it based on the help file very much and can't vouch for the help file's accuracy.
To see valid URLs, you can open UI3 and look at browser dev tools, network tab, while using the timeline with a Jpeg streaming quality selected,
Here's one simplified example URL that should get you started:
Thanks for hint!
1. Either of these URLs starts streaming the video in the browser starting 2 minutes ago
http://192.168.1.3:8600/time/DW1?mjpeg&h=520&pos=-120000http://192.168.1.3:8600/time/DW1?mode=mjpeg&h=520&pos=-120000BTW, the
stream= argument is ignored. The playback matches what you see when you playback the clip in the application.For other tweakers, the size argument
h=520 is not needed, but I used it so I could overlay the browser frame over the application live stream to more easily compare the timestamps.2. Either of these URLs grab the BVR's image in the browser starting 2 minutes ago
http://192.168.1.3:8600/time/DW1?jpeg&h=520&pos=-120000http://192.168.1.3:8600/time/DW1?mode=jpeg&h=520&pos=-120000
Last edited:
Heads-up. Once the stream playback in the browser matches the current time, output terminates.
You can test this using the
Additionally, the displayed stream will not go back to the previous clip. That is, if the currently recording BVR started at 10:00, and the current time is 10:01, then the above URL will start the stream at 10:00. It will not stream from the previous clip starting at 09:59.
You can test this using the
speed= argument:Additionally, the displayed stream will not go back to the previous clip. That is, if the currently recording BVR started at 10:00, and the current time is 10:01, then the above URL will start the stream at 10:00. It will not stream from the previous clip starting at 09:59.
Last edited:
@bp2008 - It seems UI3 already supports this. Is this correct?
I just tried this URL with success
Furthermore, this URL will start streaming from a previous clip if the
Is this new feature? I vaguely recall asking before if this was possible, and receiving a negative response.
I just tried this URL with success
http://192.168.1.3:8600/ui3.htm?cam=DW1&timeline=-120000Furthermore, this URL will start streaming from a previous clip if the
timeline= URL parameter exceeds the recorded time of the current clip.Is this new feature? I vaguely recall asking before if this was possible, and receiving a negative response.
Technically yes it is optional but I get the impression you think it is related to main stream vs sub stream. That isn't its function. The
stream= argument tells BI which of the web server encoding profiles to use. So I think your stream is based on "Streaming 0" whether you include stream=0 or not, but you could change it to stream=1 to use the "Streaming 1" profile, or stream=2 to use "Streaming 2". I think for jpeg/mjpeg streams all it matters for is the encoding quality, which you can normally override with a q= argument anyway. Maybe it also affects the "max frame size" if you omit w= and h= arguments. I'm not sure.
This has been in since the timeline originally launched in UI3. The exact behavior is really up to Blue Iris; UI3 just starts requesting timeline video at the specified date or offset and maybe you have "skip dead air" configured or not.
| timeline=DATE tl= | Opens the timeline tab and seeks to the specified date and time. The "DATE" value can be:
|
So basically during UI3's startup if it sees
timeline=-120000 then UI3 will automatically open the Timeline tab and scroll back 2 minutes. UI3's timeline interface really does not care about clip boundaries and bases all playback decisions around a time offset.
The timeline playback API, by design, can be queried for ANY date that has already passed (I think January 1, 1970 is the minimum date), and if there is no clip at the requested time, then Blue Iris either delivers a gray box saying "No Video" or seeks to the next clip (if you have the "skip dead air" feature enabled). In my experience the Skip Dead Air feature is buggy and can often fail to identify the clip it should, causing it to instead load the next one. That is probably what you've encountered in your mjpeg test rather than any "new" bug. I just never use the skip dead air feature so I don't care enough to submit a bug report myself.
I don't think I'm intentionally using the "skip dead air" feature.
I'll email Ken after confirming and testing a few more cameras.
I stand corrected.
After disabling this setting, the response was the same. I emailed Ken.
The Help PDF says this feature was implemented in 5.5.5 (February 2, 2022). I'm guessing my request probably pre-dated this.