5.9.9 - January 17, 2025 - More Pre-6.0 feature releases

And when the system crashes? All is lost?

Either something has been lost in translation there, or... yikes

Surely that can't be accurate
 
Yep looking at modified dates, even stranger is it’s the 20th today but the extra file is dated last modified yesterday at around the time I restarted the VM?IMG_2430.png
 
Last edited:
More from Ken about the new 'records.dat' and 'extra.dat' database files...

Me....

Does the 'records.dat' file play a role in the event that Blue Iris crashes or fails to shut down gracefully?

Ken...

The files should be closed and db saved when the software crashes. However if the os or pc crashes, data will be lost. In today's update I am going to do some buffer flushes and write through such that data does not remain unwritten in the event of a full system crash.
 
  • Like
Reactions: msantic and Oneup
5.9.9.81

Help PDF: not updated

Changelog...

Known issues
• Remote management has not been extensively tested against the new database code. The timeline display will be missing until a future release.

[5.9.9.81] – 2025-09-21

Added
• N/A

Fixed
• Crash occurring when unwinding multiple camera/group readers sharing H.264 compression
• Export to unmanaged folder appearing in clips list
• Alert bitmaps used for alert actions sourced from the DB may have been absent.
• Remote management Status/Log not refreshing
• Remote management clips/alerts list not populating
• Filtering clips list by subfolder had no effect

Changed
• Alert memos with opening ( without matching ) are now truncated before the (
• The text limit on the "limit access by IP address" box on Settings/Web server/Advanced has been increased from a control default of 32768 to the maximum possible number of characters, 65535.
• Export/Move from the clips view has changed behavior when multiple files are selected. If a file is missing, the prompt will display the filename, but continue to move other files. If an alert has only a .DAT file, that will be moved regardless of the presence of an associated JPEG file.
 
I’m still not getting any indication of recordings present when looking at a calendar view, as I said before I used to get a red circle before to indicate that there is a recording.
 
I’m still not getting any indication of recordings present when looking at a calendar view, as I said before I used to get a red circle before to indicate that there is a recording.
Did you mean like these:

Screenshot 2025-09-22 071102.jpg


I only get them on clips not on alerts. Also, mine acted goofy at first, I had none but after toggling between clips and alerts, they suddenly showed up.
 
  • Like
Reactions: IAmATeaf
I’ve had a play, if I deselect single cam view then I can see the red dots but if I select the single cam view then depending on the cam most disappear but there are random ones but they don’t align with the actual recordings.

There is def something cocky going on with these red indicators unless my test system is somehow all screwed up
 
  • Like
Reactions: Tinman
I’ve had a play, if I deselect single cam view then I can see the red dots but if I select the single cam view then depending on the cam most disappear but there are random ones but they don’t align with the actual recordings.

There is def something cocky going on with these red indicators unless my test system is somehow all screwed up
Exactly...I see the same thing. The challenge is trying to explain it to BI support :)

Screenshot 2025-09-22 085119.jpg
 
  • Like
Reactions: IAmATeaf
My red dots on that calendar view are also completely wonky. My clip list shows red dots on every Monday, Tuesday, and Saturday. My alert list is the opposite set of days (missing Monday, Tuesday, Saturday). Haha.

With the lists filtered to a single camera it is usually just empty or may have a random day with a red dot.

Assuming some of you guys are reporting this to BI support I will not bother to do the same.
 

Attachments

  • 1758549514882.png
    1758549514882.png
    22.4 KB · Views: 0
  • Like
Reactions: IAmATeaf
My red dots on that calendar view are also completely wonky. My clip list shows red dots on every Monday, Tuesday, and Saturday. My alert list is the opposite set of days (missing Monday, Tuesday, Saturday). Haha.

With the lists filtered to a single camera it is usually just empty or may have a random day with a red dot.

Assuming some of you guys are reporting this to BI support I will not bother to do the same.
Yes I sent a note to support.
 
  • Like
Reactions: IAmATeaf
A HEADS-UP to anyone using the JSON camlist command.

Ken has intentionally changed the name of All Cameras group in the JSON camlist response from capitalized 'Index' to lowercase 'index'.

If you've got any code/scripts/etc. that expects the case-sensitive group name, then, like me, you've got some editing to do.

Ken's response...

Yes I did that purposely for consistency/readability. My code was always using a case-insensitive comparison. Sorry for the disruption.
 
  • Like
Reactions: looney2ns
I’ve had a play, if I deselect single cam view then I can see the red dots but if I select the single cam view then depending on the cam most disappear but there are random ones but they don’t align with the actual recordings.

There is def something cocky going on with these red indicators unless my test system is somehow all screwed up
Supposed to be fixed on 5.9.9.82

UPDATE mine works fine now on 5.9.9.82 :)
 
Last edited:
  • Like
Reactions: IAmATeaf
5.9.9.82

Help PDF: not updated

Changelog...

Known issues
• Remote management has not been extensively tested against the new database code. The timeline display will be missing until a future release

[5.9.9.82] – 2025-09-22

Added
• N/A

Fixed
• Crash during DB repair when adding records are crossing an expansion threshold boundary (10,000 records)
• Invalid JPEG return to the client app when an alert has been deleted, causing the app to flicker as it tried to continuously reload the image.
• Dots display on some calendar views
• Hang introduced in .81 caused by alert memos with trailing spaces

Changed
• When starting with an empty DB and no legacy clips.dat file, a DB repair will automatically run to check for files to be adopted into the DB.
• Restored the “res” field for “alertlist” web services queries
• Improved use of encoding sharing with stream overrides via UI3
 
A HEADS-UP to anyone using the JSON camlist command.

Ken has intentionally changed the name of All Cameras group in the JSON camlist response from capitalized 'Index' to lowercase 'index'.

If you've got any code/scripts/etc. that expects the case-sensitive group name, then, like me, you've got some editing to do.

Ken's response...

Yes I did that purposely for consistency/readability. My code was always using a case-insensitive comparison. Sorry for the disruption.

Thanks for the heads up. Do you know what version this went into? This is causing a number of bugs in UI3 of course, mainly because I was not normalizing character case (to upper or lower case) when using camera or group IDs as part of a settings key. I have to start doing that now.

Issues discovered so far:

  • Group Settings for the "All cameras" group were lost (or, shall we say, misplaced?) because they were keyed with the name "Index", but there is no longer a group with the key of "Index". The next UI3 release will restore whatever settings were orphaned by this change, potentially overwriting folks's new settings for the All cameras group. Yippee.
  • Breaks something related to All cameras cycle stream .. not sure exactly what but it wasn't being detected properly anymore.

It seems like nobody cares about backwards compatibility anymore.