Application error

I "may" have found what was causing my errors. It's too soon yet to tell for sure but I"ve had no errors in the last 24 hours. I've gone several days before though without errors so I don't know for sure.

What I discovered that may be the cause was I had XMP (extreme memory profile) on in the camera server. The ram was rated for XMP service and Its been on for years when I used this system for general and development work with no problems but perhaps since Blue Iris with DeepStack is really working memory hard I had a timing failure or something simillar.

We'll see.

Joe
 
  • Like
Reactions: fenderman, sebastiantombs, looney2ns and 1 other person
Well, got another application error today. Code is 374 again so it doesn't appear to be a memory problem with my server. No clue at this point so I guess I'll just have to live with it.

Joe
 
kklee said:
Just tossing this out here, I had random crashes long ago and it turned out to be an issue with the Visual C++ runtime. I updated it to the latest from the Microsoft web site and the crashing went away.
Click to expand...

Thanks. I downloaded and installed the latest one available. It was newer than what I had. I also updated Blue Iris to 5.4.9.3 that just came out. We'll see how it goes now.

Joe
 
Well, it doesn't look like the C++ runtime upgrade helped. Worked fine yesterday but just got another error with exception code 374 a few minutes ago. It happened when I had Blue Iris open on the Server through Remote Desktop and I clicked on a camera to look at something on the UI3 display on the computer running Remote Desktop to the camera server. Maybe just a coincidence.

I've decided to disable DeepStack to see if that might make a difference. Probably won't but thought it was worth a try.

edit: That didn't take long. 3 minutes after I disabled DeepStack I had another 374 error. Guess that lets DeepStack off the hook.
 
Last edited:
Well, it's now been a week since I turned DeepStack off and I've not had a single Blue Iris crash. That doesn't necessarily mean the crashes were caused by DeepStack but is interesting none the less. I was running the CPU version of DeepStack.

On days with lots of sun, passing clouds, and wind, DeepStack pushed my CPU to 100% peaks so it really worked hard. I didn't notice that the hardware errors aligned with this type day, however. On the contrary, they seemed random. Perhaps something is marginal hardware wise that is causing this but memory would be my first thought and I've swapped that out. It's also not hardware acceleration as it has been on this past week, as always, and not a glitch in anything with DeepStack off.

Still a mystery.

Joe
 
I found the App restarting, via email alerts. Bi is running as a service. Checked event viewer yadayadayada,,,, event 7304 or 7300
clicked on the Status icon (graph/lightning bolt icon) in BI’s main page. And looked at what the stats were.
Looking down the list, the data that was an outlier was FPS/Key ratio.
the 2 Jidetech ptz were showing weird ratios. Remembering another Jidetech owner had showed me the “IP” box in one page of camera settings was actually key frames. So i made the Camera’s FPS 10 and the IP thing 10. On both cameras.
rechecked “Status” and the data was more normal like the Dahua cams were reporting.
Since then(Wed 07/07/21) the email alerts have stopped reporting the App restarting.
 
  • Like
Reactions: sebastiantombs
The outdoor jidetech ptz was missing video on the timeline in chunks,,,like 4 hours or more. On the same days as the restarts. What i wish i hadn’t done was revert back from 5.4.7.11 to like 5.4.5.3 in frustration. But in 5.4.5.3 is where i picked up on the wonky FPS/Key ratio on the Jidetechs.
 
  • Like
Reactions: sebastiantombs
You sure those cameras really aren't named "Jivetech"?
 
  • Haha
Reactions: Flintstone61
You must log in or register to reply here.
Top Bottom