Redrawing the screen sometimes causes some slow stopping streams to not be redrawn

[SvenVD]

Reported in https://ipcamtalk.com/threads/raspbery-pi2-camera-monitor-w-rpisurv.8990/page-8#post-319322

Tried rpisurv v2.0 and like it very much ...

One thing I noticed is that when I have a screen with 4 cams and one cam disconnects abruptly due to a crash / sudden power off then the screen update which tries to redraw all four camera streams again might sometimes fail to properly display the three other cams.

This seems to be an issue with a race condition.

In the example below I use a config with the default "disable_probing_for_all_streams: False" and I have just killed the rtsp stream used by screen1_cam_stream4. The screen1_cam_stream1 and screen1_cam_stream2 streams will now indefinitely show "connecting to camera.." ..

Code:

2018/12/15 17:25:00 - l_default - DEBUG - ScreenManager: update_connectable_camera_streams, disable_probing_for_all_streams is off for this screen, so using probes screen1
2018/12/15 17:25:00 - l_default - DEBUG - Screen: screen1 Connectable camera streams changed from 4 to 3 or we change from previous_cached value: False to current cached value: False, screen: screen1 needs update/redraw
2018/12/15 17:25:00 - l_default - DEBUG - CameraStream: Stop stream screen1_cam_stream1
2018/12/15 17:25:00 - l_default - DEBUG - CameraStream: MAIN Value of stopworker for screen1_cam_stream1 is 1
2018/12/15 17:25:00 - l_default - DEBUG - CameraStream: Stop stream screen1_cam_stream2
2018/12/15 17:25:00 - l_default - DEBUG - CameraStream: MAIN Value of stopworker for screen1_cam_stream2 is 1
2018/12/15 17:25:00 - l_default - DEBUG - CameraStream: Stop stream screen1_cam_stream3
2018/12/15 17:25:00 - l_default - DEBUG - CameraStream: MAIN Value of stopworker for screen1_cam_stream3 is 1
2018/12/15 17:25:00 - l_default - DEBUG - CameraStream: Stop stream screen1_cam_stream4
2018/12/15 17:25:00 - l_default - DEBUG - CameraStream: MAIN Value of stopworker for screen1_cam_stream4 is 1
2018/12/15 17:25:00 - l_default - DEBUG - Screen: screen1 number of fields= 3
2018/12/15 17:25:00 - l_default - DEBUG - blanking the screen
....
2018/12/15 17:25:00 - l_default - DEBUG - CameraStream: Worker from screen1_cam_stream1 is still alive not starting new worker
...
2018/12/15 17:25:00 - l_default - DEBUG - CameraStream: Worker from screen1_cam_stream2 is still alive not starting new worker
_cam_stream3

Problem seems to be that the actual stop of the worker threads for the cams 1 & 2 on screen1 however takes place slightly later in time which should not happen :

Code:

2018/12/15 17:25:01 - core.worker - DEBUG - This stream screen1_cam_stream1 is about to be stopped
2018/12/15 17:25:01 - core.worker - INFO - This stream screen1_cam_stream1 has been stopped

2018/12/15 17:25:01 - core.worker - DEBUG - This stream screen1_cam_stream2 is about to be stopped
2018/12/15 17:25:01 - core.worker - INFO - This stream screen1_cam_stream2 has been stopped

Rpisurv doesn't notice anymore now that the omxplayer instances have been stopped so this causes the 'connecting to camera..' problem.