Create GIFs from alerts & clips; Send Pushover notifications with GIF attachments

Hello!

I am getting error below.

PS C:\Windows\system32> BI_gif_tool.ps1 -UI3Rec '287499540-337764'
BIJsonClipstats() json_response_obj.result = fail
{
"result": "fail",
"session": "66f92465573061653cdf6cb438133f4c"
}
ERR/unexpected response from MakeGIF(): 'ERR/unable to get clipstats for database record: '@287499540''
 
  • Like
Reactions: Flintstone61
Also error on:

PS C:\Windows\system32> BI_gif_tool.ps1 -Camera dah04ptz25x -Latest -IgnoreDat
ERR/unexpected response from MakeGIF(): 'ERR/BIJsonClipstats() expecting an argument (-Clips)'




This works OK.
BI_gif_tool.ps1 -Camera dah04ptz25x -Live
Getting JPGs from the Camera's Live Video Stream...

---------------------------------------------------

Executing ffmpeg:
-----------------
success

GIF File Summary:
-----------------
GIF created: 'C:\Dropbox\Bat2\BI_GIF_tool\dah04ptz25x\output.gif'
GIF method: viaLive
GIF specs: ImageCnt,Height,Dur(msec),FPS,Size(KB) = 10,320,10000,2,674
GIF archived as: 'C:\Dropbox\Bat2\BI_GIF_tool\_gif_archive\dah04ptz25x.20241117_090000.2155357.gif'
GIF source: 'J:\BlueIris\dah04ptz25x.20241117_090000.bvr'

GIF Archive Maintenance Summary:
--------------------------------
Count of archived GIF files matching 'C:\Dropbox\Bat2\BI_GIF_tool\_gif_archive\*.gif' = 2
No old GIF files found to prune (age >= 360 hrs)
Oldest GIF file age is 0 hrs (dah04ptz25x.20241117_090000.434897.gif)

Pushover Response:
------------------
Pushover notification sent

Performance Summary:
--------------------
JPG fetch delay: 0 msec
makegif execution time: 128536 msec
pushover execution time: 15971 msec
total execution time: 14527 msec

CSV Log Summary:
----------------
Performance data logged to 'C:\Dropbox\Bat2\BI_GIF_tool\BI_gif_tool_V2.2_log.csv'

Blue Iris Logfile Summary:
--------------------------

Custom BI logfile message posted
 
Last edited:
Hello!

I am getting error below.

PS C:\Windows\system32> BI_gif_tool.ps1 -UI3Rec '287499540-337764'
BIJsonClipstats() json_response_obj.result = fail
{
"result": "fail",
"session": "66f92465573061653cdf6cb438133f4c"
}
ERR/unexpected response from MakeGIF(): 'ERR/unable to get clipstats for database record: '@287499540''
Sorry about this.

Unfortunately, I haven't been able to reproduce your observations. I tried all of the following:
  1. Executing the script in powershell.exe (PS5.1), powershell_ise.exe (PS5.1) and pwsh.exe (PS7)
  2. Using a non-admin Blue Iris user account.
While examining the code I did find a bug left over from a change in V2 (when I changed argument -DbRec to -DbRecNo). I also modified the BIJsonClipstats()
to enforce the requirement that the database record be prefixed with a @.

I've added a V2.2Mod1 zip file with these "fixes" to post #1. Please give it a try.
NOTE: A new user-settings file is not provided nor needed; keep using the one provided with the V2.2 zip file.

Because I'm unable reproduce your observations, I cannot confirm that either of these are actual fixes.

If the issues persist after trying the newer script, let's try ruling out a Blue Iris database "glitch":
  1. Please try first a database 'Compact/Reindex' action.
  2. If that doesn't improve things, then try a database 'Repair/Regenerate' action.
Please keep in mind that when you use these database actions, the original UI3 rec= argument value will no longer apply. You'll need to reload the UI3 page, re-navigate to the alert, then grab the new argument value to use in the Powershell script.
 
Last edited:
Hello!

Unfortunately same error.


------------------------------------------------------
PS C:\Users\mladen> BI_gif_tool.ps1 -AlertRec '@312796519'
BIJsonClipstats() json_response_obj.result = fail
{
"result": "fail",
"session": "74bc0ba066c863084ea90df161714315"
}
ERR/unexpected response from MakeGIF(): 'ERR/DB record not found (@312796519)'

------------------------------------------------------
PS C:\Users\mladen> BI_gif_tool.ps1 -DbRecNo '312796519'
BIJsonClipstats() json_response_obj.result = fail
{
"result": "fail",
"session": "74bc0ba066c863084ea90df161714315"
}
ERR/unexpected response from MakeGIF(): 'ERR/DB record not found (@312796519)'

------------------------------------------------------
PS C:\Users\mladen> BI_gif_tool.ps1 -UI3Rec '312796519-348207'
BIJsonClipstats() json_response_obj.result = fail
{
"result": "fail",
"session": "74bc0ba066c863084ea90df161714315"
}
ERR/unexpected response from MakeGIF(): 'ERR/DB record not found (@312796519)'

------------------------------------------------------

Maybe my version of Blue Iris 5.7.3.0 is to old.

Command BI_gif_tool.ps1 -Camera dah04ptz25x -Live works OK.

Result is attached.
 

Attachments

  • dah04ptz25x.20241118_090002.1184698.gif
    dah04ptz25x.20241118_090002.1184698.gif
    115.3 KB · Views: 28
Last edited:
Hello!

Unfortunately same error.


------------------------------------------------------
PS C:\Users\mladen> BI_gif_tool.ps1 -AlertRec '@312796519'
BIJsonClipstats() json_response_obj.result = fail
{
"result": "fail",
"session": "74bc0ba066c863084ea90df161714315"
}
ERR/unexpected response from MakeGIF(): 'ERR/DB record not found (@312796519)'

------------------------------------------------------
PS C:\Users\mladen> BI_gif_tool.ps1 -DbRecNo '312796519'
BIJsonClipstats() json_response_obj.result = fail
{
"result": "fail",
"session": "74bc0ba066c863084ea90df161714315"
}
ERR/unexpected response from MakeGIF(): 'ERR/DB record not found (@312796519)'

------------------------------------------------------
PS C:\Users\mladen> BI_gif_tool.ps1 -UI3Rec '312796519-348207'
BIJsonClipstats() json_response_obj.result = fail
{
"result": "fail",
"session": "74bc0ba066c863084ea90df161714315"
}
ERR/unexpected response from MakeGIF(): 'ERR/DB record not found (@312796519)'

------------------------------------------------------

Maybe my version of Blue Iris 5.7.3.0 is to old.

Command BI_gif_tool.ps1 -Camera dah04ptz25x -Live works OK.

Result is attached.
These errors suggest that the Blue Iris JSON interface may not be recognizing your credentials. Or the username lacks the necessary privileges. Please double-check the applicable user-settings.

The software version may be a clue. I'll give it a try.
 
Last edited:
I am sure that username and password are correct and user have admin rights.
 
Script updated to V2.3. see post #1 to download the zip file.

Key features of this new version are:
  • BREAKING CHANGE: must replace old user-settings-file
  • FIXED: various bugs encountered w/ older versions of Blue Iris (tested back to 5.7.3)
  • FIXED: bug where old variable $DbRec should have been new variable $DbRecNo (originally changed in V2)
  • ADDED: new column 'PSVersion' to script's CSV log file (for future debugging info)
  • ADDED: new user setting to support older Blue Iris software versions: $require_new_json_session_keys_flg
  • IMPROVED: various optimizations / efficiency gains (see script changelog for details)
  • IMPROVED: argument -DevMode now includes detailed timing info, including: 1) timing info for JSON cmds, and 2) JSON alertlist response for argument -Latest
It may worth reiterating that this script no longer requires DAT files to create GIFs.

Why you might want to use this update:
  1. You want to use the script with older version of Blue Iris (tested back to 5.7.3)
  2. You want faster notifications
Performance results...
I'm routinely seeing GIF make times of ~3 sec for DAT files containing 10-13 JPG images.
This chart also shows Pushover notification process times.

V2.3_gif_tool_performance_viaDAT_pushover.png


Additionally, I'm seeing even faster GIF make times when extracting the JPGs from the BVR file (via argument -IgnoreDAT). Despite this, I still prefer to use DAT files because, unlike using BVR files, every frame in the GIF contains the object of interest. Using BVR files can require some 'tuning' to trim frames from the entire alert duration used to create the GIF.
 
Last edited:
  • Like
Reactions: jrbeddow
@jaydeel
Well after very successfully running the original (JPEG only) Pushover script for the last 1.5+years (maybe longer), I finally got around to testing this GIF version. It took me a couple of hours to get it working (Reminder: always reboot when testing, even if you think you have successfully refreshed the PATH through other means), but the GIF make times I am experiencing are all over the place so far. The ones created through .DAT files are relatively fast (roughly 3-4 seconds in a short set of tests), but when the script has to fallback onto using the "Clip" method (JPEGS extracted from the .BVR), the full creation times spike to 20-23 seconds! Is that directly related to the alert length (ie: the script cannot complete until the Alert clip has finished)?

I also still have the popup notification appearing on my BI console screen: what is the added switch to disable that?

I'm also still a bit confused on the whole CORRECT settings for the BI Web Server pages, as the advice seemed to change over the course of the evolution of this script: Is it still the recommended method to use the ^192.168.x.x in the Advanced box, and do I also have to uncheck the "Use secure session keys and login page" checkbox?

Now if Ken would just make it possible (perhaps in the upcoming BI Version 6?), to have the actions fully additive for motion moving into more important "area of interest" zones, during an otherwise "record only, but do not push an alert" scene. Even if this had to be implemented as a looping request in the action box (a "do while" routine) for the duration of any "New" Alert. Somehow, instead what he added was the ability to turn these events into separate Alerts (the "additive" and "exclusive" box), which I haven't found useful at all. I don't want these to become completely separate Alerts, just one contiguous one when the action moves from the sidewalk to my property after some delay, but still be alerted. Any ideas on other ways to achieve this? I've played with the wait timers, which in theory allow other zones to be added, but with mixed results at best.
 
Last edited:
I'll address these topics individually...

The popup can be disabled via setting $bg_msgs_on in the user-settings file. Think of it as a debugging tool.
It's enabled it by default to initially provide feedback that the script is actually running from the background (e.g., a Blue Iris action).
 
  • Like
Reactions: jrbeddow
Slow processing from a BVR...

New alert GIFs created from BVRs can be slow because Ken has not provided a HTTP command for extracting JPGs from the recording buffer before it's written to the BVR. So the script waits for the alert duration (good guess!) before attempting. This is in no way ideal.

To see this in real-time... from the console, try repeatedly executing a command like -Camera DW1 -Latest -IgnoreDAT - both between alerts, and just after the camera has just triggered. For the latter, you should get a warning that the alert is too 'fresh', and the script will pause until it thinks it's OK to proceed.

I've not experimented with inserting a short 'Wait' action before the the script's 'Run a program' action in the Action set, but in theory it might help... But in reality, who really wants to delay their alerts?

I've bugged Ken several times about providing a way to extract JPGs from the buffer. He's told me it is possible. Maybe now that 6.0 is is on the horizon, I'll try again.
 
  • Like
Reactions: jrbeddow
Accessing the web server via the script...

Yes, I use ^192.168.x.x in the Advanced box, and uncheck the "Use secure session keys and login page" checkbox.

But you should be able to get around this by enabling setting $post_w_creds_flg in the user-settings file, as well as populating settings $bi_user_name and $bi_user_pw with valid credentials... This works in my testing just now. Let me know if you have trouble.
 
  • Like
Reactions: jrbeddow
I finally got around to testing this GIF version. It me a couple of hours to get it working (Reminder: always reboot when testing, even if you think you have successfully refreshed the PATH through other means),
Sorry about that. This should scare off even more potential users, lol.

I'll add this tip to the installation guide.
 
  • Haha
Reactions: jrbeddow
Sorry about that. This should scare off even more potential users, lol.

I'll add this tip to the installation guide.
Yes, for quite a while I was able to complete up through Step 4: a test send from the Powershell console would work fine, but nothing would work when testing directly in BI until I finally gave in and tried a reboot, then magically it started working.

It's unfortunate we still don't have a way to reliably use the NukeDAT function, that seemed like a great idea. Although, I have other issues to solve, as I use a mix of on-camera ONVIF triggers (simultaneously) alongside BI's motion detection and CPAI, so DAT files (and the resulting speed) won't always be available to my setup. Oh well...

I really appreciate your incredible support each time I (or any other user) runs into issues running these amazing scripts, many thanks again.
 
... but the GIF make times I am experiencing are all over the place so far. The ones created through .DAT files are relatively fast (roughly 3-4 seconds in a short set of tests), but when the script has to fallback onto using the "Clip" method (JPEGS extracted from the .BVR), the full creation times spike to 20-23 seconds! Is that directly related to the alert length (ie: the script cannot complete until the Alert clip has finished)?
Currently I'm testing 5 cameras using the following command in the 'Run a program' action Params field and all are consistently creating GIFs from BVR-extracted JPGs without any delay.
Code:
"C:\ps_scripts\BI_gif_tool.ps1" -Camera '&CAM' -Latest -IgnoreDat -AlertMemo '&MEMO' -Msg """<b>&CAM</b> &MEMO <a href='&WAN/alerts/&ALERT_DB?fulljpeg'>Hi-Res</a> <a href='&WAN/ui3.htm?rec=&ALERT_DB'>UI3</a>""" -Priority 1

Is the command you struggling with using both arguments -Latest -IgnoreDat ?

BTW, you can get an 'under-the-hood' peek of the script's timings by enabling two settings in the user-settings file: $append_performance_tag_flg and $append_performance_tag_details_flg. These will append additional info to the push message (highlighted in the red box in the screenshot below).

Doing this might provide some clues on what you are observing.

1734109711381.png
 
Last edited:
  • Like
Reactions: jrbeddow
Seems I spoke too soon...

After my previous post, I started working on another project. Afterwards I decided to collect some more GIF notifications.

This time I saw reproducible delays.

Example:
Screenshot_Pushover_2.jpg

I was able to restore the previous behavior by rebooting the server.

I'm reviewing the code to look for a better way to handle this situation, or at least minimize the delay.

BTW, I misspoke earlier when I agreed with your guess that the BVR extraction delay was determined by the alert's duration. It's currently 2 * (pre-trigger record time).

EDIT: You can experiment with user-specified delay durations via argument -BvrDelayMsec.
 
Last edited:
Well, I will have a lot to look at and adjust this evening when I get home: the biggest one being adding the -IgnoreDAT setting. But given your rapid development/insights into getting this right, you might just have a new script version to test very soon :).
I'll keep you posted in the next day or two.
 
the biggest one being adding the -IgnoreDAT setting
By intent, argument -IgnoreDat should NOT be required if a DAT file does not exist for an alert. In this case, the script should default to using a BVR file, if it exists.

Please let me know if your testing indicates otherwise.
 
By intent, argument -IgnoreDat should NOT be required if a DAT file does not exist for an alert. In this case, the script should default to using a BVR file, if it exists.

Please let me know if your testing indicates otherwise.
Hmm, I haven't tested or changed anything yet, but I am fairly certain that my buffer times (om all cameras) are 12 seconds, pre-record time is 8 to 10 seconds, pre-trigger playback is 3 seconds. This might align with the notion that my GIF creation times run about 22-23 seconds (when done from the clip, rather than the DAT file), if the time needed starts at 2x pre-recording time plus another 2-4 seconds.