Fix empty ['' ] detection error messages#20
Open
v-mwalk wants to merge 1 commit into
Open
Conversation
Adapter hardcoded an empty error message on failed detections, masking the real exception. Fixing that exposed a TFLite race: periodic_check() could rebuild the shared interpreter outside inference_lock while another thread was mid-invoke on it. Moved the whole critical section inside the lock. Also corrected Parallelism from 16 to 2 for the single-TPU config, per the file's own "TPU count * 2" comment.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Blue Iris was receiving detection responses with an empty message, which broke its parsing. Three issues were causing this;
objectdetection_coral_adapter.py hardcoded "message": '' on every failed detection instead of using the captured error string, so the real failure reason never reached Blue Iris.
Fixing that exposed the real underlying exception: "There is at least 1 reference to internal data in the interpreter in the form of a numpy array or slice." In objectdetection_coral_singletpu.py, periodic_check() (which can tear down and rebuild the shared interpreter on its hourly refresh) ran outside inference_lock, while interpreter.invoke() and detect.get_objects() ran inside it. A concurrent interpreter refresh could reallocate the interpreter's tensor buffers while another in-flight request still held live numpy views into the old interpreter's output, triggering this TFLite safety check. Fixed by moving the whole critical section (periodic_check, input setup, invoke, and output extraction) inside a single inference_lock block so a refresh can never overlap an in-flight detection.
modulesettings.json had Parallelism set to 16 for a single physical Coral USB Accelerator. The file's own comment says this should be TPU count * 2, so corrected to 2. Sixteen concurrent workers queuing against one serialized device was contributing to the intermittent failures in the first place.
Verified on the Pi: restarted the service, watched live traffic from Blue Iris and client meshed, saw clean results with no empty messages and no TFLite errors.
FYI @ChrisMaunder