Once the DST occured at 2:00AM BlueIris started triggering repeated Onvif error 8000ffff on my 5 Hikvision Cameras. I use direct to disk recording and rely on the cameras to trigger BI to record. There are recordings prior to 2:00PM, nothing after. I am currently on V 5.8.7.11 but tried 5.8.8.3 and 5.8.8.2 without success. When I do an inspect I get the following results.
Opening 192.168.2.236 port 80...
HTTP Get / request...
OK
ONVIF GetSystemDateAndTime
2024-03-10T21:40:45.000Z
Requesting device information...
Manufacturer: HIKVISION
Model: DS-2CD2387G2P-LSU/SL
FirmwareVersion: V5.7.11
GetCapabilities...
Querying services
Has Search services: /onvif/SearchRecording
Has Imaging services: /onvif/Imaging
Has media services: /onvif/Media
Has RTP_RTSP_TCP, requesting profiles
profile token Profile_1
profile name mainStream
profile source is VideoSource_1
profile source config is VideoSourceToken
profile token Profile_2
profile name subStream
profile source is VideoSource_1
profile source config is VideoSourceToken
requesting URI for profile Profile_1
RTSP URI: /Streaming/Channels/101?transportmode=unicast&profile=Profile_1
requesting URI for profile Profile_2
RTSP URI: /Streaming/Channels/102?transportmode=unicast&profile=Profile_2
Has Event services: /onvif/Events
Has WSPullPointSupport
RelayOutputs: 1
RelayOutput: AlarmOut_0/Monostable/closed
InputConnectors: 1
Has Device IO services: /onvif/DeviceIO
AudioOutputs: 1
Done
ONVIF Error 8000ffff after DST occured at 2:00AM
Re: ONVIF Error 8000ffff after DST occured at 2:00AM
I had the same multiple Onvif "Events: Request 8000ffff" at exactly 3am, on most but not all cameras, but recordings were not impacted.
BI 5.8.7.11 and cpai 2.5.6
BI 5.8.7.11 and cpai 2.5.6
Re: ONVIF Error 8000ffff after DST occured at 2:00AM
I found a November post in IP Cam Talk referring to an issue with Onvif 8000ffff errors when DST ended. Seems there was a BI bug.
Re: ONVIF Error 8000ffff after DST occured at 2:00AM
2:00am is also when Blue Iris performs its daily database maintenance unless otherwise changed to a different schedule.
Could be related.
Could be related.
Re: ONVIF Error 8000ffff after DST occured at 2:00AM
Just now, ONVIF error 8000ffff ceased without me changing anything. From DST change at 2:00AM until now ONVIF connect to the hikvision cameras would not authenticate, and now, it does. I am at a loss to explain but it seems to have something to do with the DST change.
Re: ONVIF Error 8000ffff after DST occured at 2:00AM
March 2025 DST just happened (one hour ahead). I've seen this same thing for all DST time changes over the last few years and haven't gotten to the bottom of it. Here's what I've found.
I have Blue Iris 5.9.9.27 running on Windows 10. The time on the Windows 10 machine updates properly for DST. Taking a packet capture of the ONVIF HTTP POST to connect to my cameras for ONVIF events has a SOAP header with Security > UsernameToken > Created. The Created timestamp SENT from BlueIris is 1 hour ahead of where it should be sent as UTC (Zulu). Example, my timezone is GMT -5, but being spring DST we effectively use GMT -4 now. BlueIris should add +4 hours to the local computer time to get the current UTC time for the timestamp, but it is adding +5. The camera rejects this incorrect UTC timestamp for ONVIF authentication.
If I change the time of the Windows 10 machine running Blue Iris to be 1 hour BEHIND of the actual local time by disabling 'adjust for DST' then restart the Blue Iris windows service, ONVIF works again and the errors go away. This is because the timestamp in the SOAP UsernameToken is now sent as the correct UTC time.
If I change the timezone on my Windows 10 machine to by GMT -4, and leave 'adjust for DST' ENABLED, the timestamp in the ONVIF message is wrong still, 1 hour ahead of where it should be.
From these tests it appears Blue Iris uses the Windows 10 system time as seen by the user on the 'clock', then applies the timezone offset for the ONVIF timestamp.
Is Blue Iris using the Windows API to get time to use in the ONVIF SOAP message? I've found these messages about handling DST from the API.
https://www.vbforums.com/showthread.php ... ost5407269
https://www.vbforums.com/showthread.php ... ost5407275
In the help documentation I see reference for the Windows Location API which I'm not sure if that is used for ONVIF or only location related features. I do have Windows Location Services disabled (might be a factor).
I remember previously that Blue Iris 'fixes' itself if you wait about a day. I am going to re-confirm this in a few hours. If this is true, maybe Blue Iris does a scheduled sync of the Windows timezone/DST that eventually gets the ONVIF timestamp updated. If this is a scheduled sync by Blue Iris there is opportunity for improvement to more quickly fix the timestamp to avoid ONVIF errors.
I have Blue Iris 5.9.9.27 running on Windows 10. The time on the Windows 10 machine updates properly for DST. Taking a packet capture of the ONVIF HTTP POST to connect to my cameras for ONVIF events has a SOAP header with Security > UsernameToken > Created. The Created timestamp SENT from BlueIris is 1 hour ahead of where it should be sent as UTC (Zulu). Example, my timezone is GMT -5, but being spring DST we effectively use GMT -4 now. BlueIris should add +4 hours to the local computer time to get the current UTC time for the timestamp, but it is adding +5. The camera rejects this incorrect UTC timestamp for ONVIF authentication.
If I change the time of the Windows 10 machine running Blue Iris to be 1 hour BEHIND of the actual local time by disabling 'adjust for DST' then restart the Blue Iris windows service, ONVIF works again and the errors go away. This is because the timestamp in the SOAP UsernameToken is now sent as the correct UTC time.
If I change the timezone on my Windows 10 machine to by GMT -4, and leave 'adjust for DST' ENABLED, the timestamp in the ONVIF message is wrong still, 1 hour ahead of where it should be.
From these tests it appears Blue Iris uses the Windows 10 system time as seen by the user on the 'clock', then applies the timezone offset for the ONVIF timestamp.
Is Blue Iris using the Windows API to get time to use in the ONVIF SOAP message? I've found these messages about handling DST from the API.
https://www.vbforums.com/showthread.php ... ost5407269
https://www.vbforums.com/showthread.php ... ost5407275
In the help documentation I see reference for the Windows Location API which I'm not sure if that is used for ONVIF or only location related features. I do have Windows Location Services disabled (might be a factor).
I remember previously that Blue Iris 'fixes' itself if you wait about a day. I am going to re-confirm this in a few hours. If this is true, maybe Blue Iris does a scheduled sync of the Windows timezone/DST that eventually gets the ONVIF timestamp updated. If this is a scheduled sync by Blue Iris there is opportunity for improvement to more quickly fix the timestamp to avoid ONVIF errors.
Re: ONVIF Error 8000ffff after DST occured at 2:00AM
I had the same issue, but with only 3 cameras. After around 8:30 PST on 3/9 the authentications on the 3 started working again. My other 12 cameras were unaffected. The 3 problem children had just had the latest Hikvision FW installed on them.
Re: ONVIF Error 8000ffff after DST occured at 2:00AM
I waited just over 24 hours after the DST time change and the timestamps were still wrong (one hour ahead of UCT). I restarted the Blue Iris service and nothing changed. I then rebooted the Windows 10 machine Blue Iris is running on completely, and now the timestamps are correct. I did reboot yesterday a few times, less than 24 hours after the DST change and the timestamps did not change.
I'm unsure if this is a Blue Iris or Windows but it does happen every time DST starts or ends.
The incorrect timestamps for me happened with all my cameras which include a mix of Hikvision and Dahua cameras that are a few years old and are running the latest firmware version available (now they are End of Life, no more updates). I don't think the camera has anything to do with it because the first HTTP ONVIF message is sent by Blue Iris not the camera with a timestamp. Additionally ONVIF Device Manager (test tool) connects to the cameras properly with authentication during the same time that Blue Iris cannot.
I'm unsure if this is a Blue Iris or Windows but it does happen every time DST starts or ends.
The incorrect timestamps for me happened with all my cameras which include a mix of Hikvision and Dahua cameras that are a few years old and are running the latest firmware version available (now they are End of Life, no more updates). I don't think the camera has anything to do with it because the first HTTP ONVIF message is sent by Blue Iris not the camera with a timestamp. Additionally ONVIF Device Manager (test tool) connects to the cameras properly with authentication during the same time that Blue Iris cannot.