5.2.9 - May 26, 2020 - Dual Stack IPv6 Support

fenderman

fenderman

Staff member
Mar 9, 2014
36,892
21,407
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.
 
  • Like
Reactions: sebastiantombs and Flintstone61
Does this mean no more port forwarding? Or vpn?


Sent from my iPhone using Tapatalk
 
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
 
  • Like
Reactions: looney2ns, beepsilver, DarkHelmet and 1 other person
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...

[tool] [tutorial] Free AI Person Detection for Blue Iris

It is not integrated yet. I just have it running next to blueiris for now.
ipcamtalk.com ipcamtalk.com
 
Last edited:
  • Like
Reactions: m_listed
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:
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
 
@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.
 
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.
 
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.
 
kklee said:
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.
Click to expand...

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 said:
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.
Click to expand...

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 ...
 
  • Like
Reactions: beepsilver and fenderman
pozzello said:
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
Click to expand...
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.
 
NielK said:
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 ...
Click to expand...
I applied this update today and did not fix the issue for me.
 
fwiw, 5.2..9.18 so far appears to have addressed the problem i was seeing. i suspect Millstone is chasing something else...
 
  • Like
Reactions: fenderman
pozzello said:
fwiw, 5.2..9.18 so far appears to have addressed the problem i was seeing. i suspect Millstone is chasing something else...
Click to expand...

@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:
You must log in or register to reply here.
Top Bottom