Fix reolink patrol

[MateoLostanlen]

The Reolink cameras regularly freeze. To avoid this issue, we propose regularly checking whether the camera poses are changing. If they are not, we reboot the camera

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.74%. Comparing base (6d525b1) to head (2df4b93).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop     #360   +/-   ##
========================================
  Coverage    72.74%   72.74%           
========================================
  Files            6        6           
  Lines          631      631           
========================================
  Hits           459      459           
  Misses         172      172           

Flag	Coverage Δ
unittests	72.74% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[fe51]

Thanks a lot for the PR, seems mainly fine, but one quesiton

stuck_check_loop runs in a separate thread from patrol_loop, and both access cam.last_images concurrently.

stuck_check_loop runs in a separate thread from patrol_loop, and both access cam.last_images concurrently. The cam.last_images.clear() call after a reboot (stuck_detector.py line 166) can race with the patrol loop iterating the same dict and raise RuntimeError: dictionary changed size during iteration. Would it be safe to replace clear() with resetting only the known pose keys, or add a small lock shared with the patrol loop?
=> I am not mastering threading but I spot this potentiel conflit -> What do you think ? Would it be an issue ?

[fe51]

Minor naming question: stuck_check_loop calls its first argument camera_ip, but main.py passes cam_id to it (the CAMERA_REGISTRY loop variable). Since CAMERA_REGISTRY is keyed by IP here the name is technically correct, but renaming the parameter to cam_id in stuck_detector.py would align with main.py and patrol.py conventions.
what do you think ?

[MateoLostanlen]

Good point. I’d rather avoid renaming only stuck_detector.py in this PR: in pyro-engine, cam_id means the camera-pose identifier ("{ip}_{p}"), while here we are passing the CAMERA_REGISTRY key, which is the camera IP. So the cleaner fix would actually be to rename the cam_id loop variable in main.py to camera_ip, and possibly harmonize similar cases elsewhere. I’ll open a follow-up issue for that cleanup instead of expanding this PR scope

[MateoLostanlen]

#368

[MateoLostanlen]

Hi @fe51 Good catch ! The real race is in stuck_check_loop: it iterates cam.last_images.items() while the patrol loop can add new pose keys at the same time, especially right after clear() repopulates them. That throws RuntimeError: dictionary changed size during iteration and silently kills the detector thread

Fixed in 5558279: I now read by known pose key (cam.cam_poses, set at startup) instead of iterating the dict, and reset by key (last_images[p] = None) instead of calling clear(). No dict mutation, no lock needed