5.2.9 - May 26, 2020 - Dual Stack IPv6 Support

fenderman

Staff member
Joined
Mar 9, 2014
Messages
34,128
Reaction score
14,129
5.2.9 - May 26, 2020
Support for IPv6 addresses in a “dual stack” mode. If your router provides an LAN IPv6
address for your PC, you will now see this on the LAN IP list on Settings/Web server. If
your router and ISP support IPv6, you may now connect to your Blue Iris service this way
remotely as well. Unless you select to bind to a single address, the software will accept
connections from both IP4 and IPv6 addresses.
IPv6 may also be used for camera addresses on your LAN or elsewhere.
 

brad2388

Getting the hang of it
Joined
Oct 5, 2016
Messages
157
Reaction score
23
Does this mean no more port forwarding? Or vpn?


Sent from my iPhone using Tapatalk
 

wittaj

Known around here
Joined
Apr 28, 2019
Messages
2,413
Reaction score
2,412
Location
USA
This update seemed to also add a column for HA instead of just the # (unless I missed it in an earlier version)

1591036110638.png
 

jaydeel

BIT Beta Team
Joined
Nov 9, 2016
Messages
318
Reaction score
224
Location
SF Bay Area
Here are three HTTP interface commands Ken fixed/modified with v 5.2.9.6...
I have verified that they work on my system.

1. The trigger ‘Reset’ command /admin/camera=x&trigger=0 now works with the ‘External’ & ‘Motion’ sources as well as the ‘ONVIF’ source. In Ken’s words... “This option exists to cancel the ONVIF trigger, where the camera determines when to start/stop the trigger start. I like your thinking however ... if not currently ONVIF triggered, trigger=0 will now cancel the active trigger in version 5.2.9.6.

BENEFIT? Now when you simulate triggers to test Action sets, instead of waiting the entire break time for the trigger to complete, you can kill the trigger early with the reset command.
1591242448199.jpeg

2. The /alerts/{filename}&fulljpeg command was previouly restarting Blue Iris when it was executed AND a hi-res alert image did not exist... This is now fixed.
1591242883169.jpeg

3. The /admin?camera=x&flagalert now works when previously it did not.
in Ken’s words ... “one issue I see is that this would not survive a restart of the software, the "last alert" information was in RAM only. I have adjusted this for the next version and it appears to be working.”
Note: The argument “=1” is not required per my testing.
1591243248662.jpeg
 

DarkHelmet

Getting the hang of it
Joined
Feb 26, 2017
Messages
149
Reaction score
58
Did anybody mention UI3 now shows main streams when opening a single cam? Not sure when that started, but working on .11 and I'm sure before that..
 

jaydeel

BIT Beta Team
Joined
Nov 9, 2016
Messages
318
Reaction score
224
Location
SF Bay Area
Here's another addition to 5.2.9 (became available in 5.2.9.12)...

If you use External source alerts via the HTTP Interface command /admin?camera=x&trigger&memo=text ,
Ken has just made the memo string accessible via a new 'memo' key in the JSON 'alertlist' command reply.

Furthermore, when it exists, the memo text appears in the clip list (instead of 'EXTERNAL')
1591652020577.png

More info here...
 
Last edited:

jaydeel

BIT Beta Team
Joined
Nov 9, 2016
Messages
318
Reaction score
224
Location
SF Bay Area
As of 5.2.9.14, Ken has a added a filter to the /clips/ command...

/clips/?match=x ... x may contain * and ? and is case insensitive

NOTE: To use this command, you must check 'Allow directory listing' in the Web server page > Advanced dialog.

I've experimented and these examples work...
/clips/?match=* ... all files
/clips/?match=*06/09* ... all June 9 files
/clips/?match=*05:* ... all 05:00 hour files
/clips/?match=*FD* ... all camera shortname 'FD' files
/clips/?match=*05:*FD*jpg* ... all 05:00 hour*.jpg files for camera shortname 'FD'

For demonstration, here's the output of the last example...
(the event schedule for this camera takes a daily snapshot at sunrise.)

1591818419480.png

FINAL NOTE... I've found it necessary to enclose all queries in with asterisks... e.g., this syntax returns no files:
/clips/?match=05:*FD*jpg
 
Last edited:

pozzello

Known around here
Joined
Oct 7, 2015
Messages
2,176
Reaction score
983
anyone else have issues with displayed timestamps of clips as of 5.2..9.17? i upgraded from .16 on 6/12, and all new clips since then have bogus timestamps displayed in the clips list in console and UI3. rebuilt the db to no effect. I have an email into support, but just wondering if anyone else has noticed/reported this?

bad_clip_timestamps.PNG
 

NielK

n3wb
Joined
Jan 2, 2018
Messages
20
Reaction score
18
@pozzello

I have a very similar issue and it's reliably reproducible.

I can fix this by: right-click on live camera tile, then “Restart Camera”.

I can reliably cause the fault to happen again by: disconnecting the camera long enough for BI to notice that the connection has been lost and then restored (eg by power-cycling the camera or rebooting it from its web interface).

This problem is repeatable only when using a substream for the camera. If I revert to the main stream only, it doesn’t seem to happen.

I've sent a report in to the support address.
 

pozzello

Known around here
Joined
Oct 7, 2015
Messages
2,176
Reaction score
983
nice job reproducing and isolating the issue, NielK!

I hadn't noticed it only occurs for cams with substream enabled, but now that you mention it, can confirm that.

restarted all my sub-stream enabled cams for now, but of course, previous erroneously-timestamped clips stay as-is...

hopefully Ken will be able to sort it out with that info.
 

kklee

Getting the hang of it
Joined
May 9, 2020
Messages
80
Reaction score
71
Location
Vancouver, BC
Others have reported this problem to Ken as well. I have this problem only with one of my cameras and I found that turning off the "Use RTSP/stream timecode" setting on the camera config in BI fixes the problem.
 

NielK

n3wb
Joined
Jan 2, 2018
Messages
20
Reaction score
18
Others have reported this problem to Ken as well. I have this problem only with one of my cameras and I found that turning off the "Use RTSP/stream timecode" setting on the camera config in BI fixes the problem.
Interesting. I get the problem on all 10 cameras. Just tried switching off "RTSP/steam timecode" and reenabling substream on three cameras. I'm afraid it didn't fix the problem - again the camera disconnect/reconnect triggered the problem.
 

NielK

n3wb
Joined
Jan 2, 2018
Messages
20
Reaction score
18
Interesting. I get the problem on all 10 cameras. Just tried switching off "RTSP/steam timecode" and reenabling substream on three cameras. I'm afraid it didn't fix the problem - again the camera disconnect/reconnect triggered the problem.
Ken got back to me for some more info. He has just released a new version (5.2.9.18) that appears to have fixed the problem.

I have all cameras back on substream, RTSP/stream timecode is on. After an hour and several camera reboots, the Clips List is still showing the right times. I'll check again in the morning. But promising ...
 

Millstone

Young grasshopper
Joined
Dec 22, 2014
Messages
98
Reaction score
22
anyone else have issues with displayed timestamps of clips as of 5.2..9.17? i upgraded from .16 on 6/12, and all new clips since then have bogus timestamps displayed in the clips list in console and UI3. rebuilt the db to no effect. I have an email into support, but just wondering if anyone else has noticed/reported this?

View attachment 63949
Yes it's been talked about in the sub-stream thread. Me and a handful of other users have it. I've been taking aim today at the NIC and Cisco switch that is attached to these particular NVRs that give me these issues (each with over 40 cameras, each pulling in streams from Dahua DVRs and IP cams), disabling flow control and bringing MTU back to defaults, etc, but I'm not sure this has had a positive effect. I've tried re-creating these cameras and still the same behaviour. My systems with ~15 cameras or so apiece don't have this issue.
 

Millstone

Young grasshopper
Joined
Dec 22, 2014
Messages
98
Reaction score
22
Ken got back to me for some more info. He has just released a new version (5.2.9.18) that appears to have fixed the problem.

I have all cameras back on substream, RTSP/stream timecode is on. After an hour and several camera reboots, the Clips List is still showing the right times. I'll check again in the morning. But promising ...
I applied this update today and did not fix the issue for me.
 

pozzello

Known around here
Joined
Oct 7, 2015
Messages
2,176
Reaction score
983
fwiw, 5.2..9.18 so far appears to have addressed the problem i was seeing. i suspect Millstone is chasing something else...
 

NielK

n3wb
Joined
Jan 2, 2018
Messages
20
Reaction score
18
fwiw, 5.2..9.18 so far appears to have addressed the problem i was seeing. i suspect Millstone is chasing something else...
@pozzello 12 hours and multiple camera disconnections / reboots later, the Clips List is still OK. Looks like the problem (that we were reporting) has been fixed. As you say, it looks like there are still some unresolved issues affecting @Millstone's setup. He did note that his affected systems had over 40 cameras whereas mine has only 10 cameras (540 MP/sec native; 67MP/sec with substreams).
 
Last edited:
Top