Cameras dropping out

No the dropouts are not related to the database...its a signal issue..can be the cams, the network, the blue iris pc, blue iris...

I finally solved this problem and in the end it was simple.

I happened to notice that the last time there was any data recorded was when I last logged on. That was a fairly small file. It also seemed to me that files previous to that were also small and were timed at about the times I had logged onto this server. I hadn't made that connection before.

Remember that I said we run BI as a service? We’ve done that since first installing. When we upgraded to version 4 it seemed that all our settings were carried forward from the prior version. It turns out the check box for “run as a service” was an exception. So, all this time, when I thought we should have been recording, we were not, because that box remained unchecked.

After discovering that a couple of hours ago, and checking the box, recording now seems to be back to normal. Mystery and problem solved.
 
  • Like
Reactions: fenderman
No the dropouts are not related to the database...its a signal issue..can be the cams, the network, the blue iris pc, blue iris...

Well, too good to be true! Recorded solidly for a day then stopped once more, this time with a write error message suggesting that suggests the recording device was either disconnected or write protected. That is definitely not the case and there is still in excess of 3TB of free space. What factors in the software, thinking buffer sizes, etc. might be related to the problem?
 
Well, too good to be true! Recorded solidly for a day then stopped once more, this time with a write error message suggesting that suggests the recording device was either disconnected or write protected. That is definitely not the case and there is still in excess of 3TB of free space. What factors in the software, thinking buffer sizes, etc. might be related to the problem?
Are there any errors logged by blue iris?
 
Are there any errors logged by blue iris?

Nothing appears to be logged by BI. The system log has a series of warning messages relating to disk writes but in clear MS tradition they are obscure. They seem to refer to page file writes, which, if that were the case would go to the C: drive, not the drive that BI is recording to.

On second thought with 16GB of main memory and only BI running there should be no need for a page file at all. Will make that change.
 
Try writing to the C drive.. See if that helps..
Are you writing to nas or USB?
Sent via Taptalk
 
Try writing to the C drive.. See if that helps..
Are you writing to nas or USB?
Sent via Taptalk

Writing to the C: drive would be an option if this wasn't a server class racked machine, as opposed to desktop workstation. One characteristic of many racked servers is that the C: drive is often small and only hold the OS and a one or more application programs. This machine has only one drive, a 73GB SCSI with the OS, BI, and some utility programs. There's less than 30GB storage left. I'm writing to an external USB connected drive to keep this traffic off our network and off the network storage array.

I removed the page file option since there should be little reason for BI to need that. The primary disadvantage is that without a page file some, but not necessarily all, crash messages might be lost. Will see how it works over the next couple of days.
 
Writing to the C: drive would be an option if this wasn't a server class racked machine, as opposed to desktop workstation. One characteristic of many racked servers is that the C: drive is often small and only hold the OS and a one or more application programs. This machine has only one drive, a 73GB SCSI with the OS, BI, and some utility programs. There's less than 30GB storage left. I'm writing to an external USB connected drive to keep this traffic off our network and off the network storage array.

I removed the page file option since there should be little reason for BI to need that. The primary disadvantage is that without a page file some, but not necessarily all, crash messages might be lost. Will see how it works over the next couple of days.
I would write to the c drive for a few days, keep the size limit small, simply to test...it could be a usb connection issue...
 
hmmm, maybe to another internal drive then...or even NAS..just to eliminate usb.

This is a 1U racked server. There are no other internal drives, or drive bays. And while I could write across the network to a NAS that puts the BI traffic in contention with other network traffic whereas writing to the attached drive is direct. I do understand the USB bandwidth and related issues, so will keep that in mind. I increased all the BI buffers to 30MB since there's plenty of main memory available. I'll see how it goes over the next few days. I can always bump the buffer sizes if problems continue. I'm also keeping in mind that the only logged events were warning messages apparently related to the page file, which is now eliminated. I'll take a look at the logs later today.
 
I know in my experience with a USB connected drive when I used record on motion there were times that I would not get the event fully recorded. Sometimes I would get a few seconds of record with a pause, then the last bit of record after motion trigger. I since moved to 24/7 record with motion trigger clips and have not had this problem. I was assuming that my drive was going to sleep during down time and spinning it back up from a motion trigger event was the culprit. Sounds like you are recording constant during work hours, yes? If so, this isn't likely the case with your setup, just giving you a little more info in case it could help.
 
I know in my experience with a USB connected drive when I used record on motion there were times that I would not get the event fully recorded. Sometimes I would get a few seconds of record with a pause, then the last bit of record after motion trigger. I since moved to 24/7 record with motion trigger clips and have not had this problem. I was assuming that my drive was going to sleep during down time and spinning it back up from a motion trigger event was the culprit. Sounds like you are recording constant during work hours, yes? If so, this isn't likely the case with your setup, just giving you a little more info in case it could help.

My configuration is as simplified as I could make it. Continuous record 24 X 7 X 365, no alerts, no audio, no posting or streaming, no motion triggers, nothing that should interfere with an uninterrupted video stream from each of the 8 cams. And the cams are set to a modest 5 FPS frame rate, which the hardware should be able to handle without difficulty.