Sequence 600s countdown took 2 hours (Dispatcher overload warning?)
Posted: Sun Sep 03, 2023 8:36 am
The following issue was encountered using version 4.1.11003.0-64bit under Windows 10 running under Parallels on an Intel MacBook Pro.
I started a sequence at 01:39:58 to capture darks at two temps with the following series of operations:
1) Capture darks for 30s exposures @ bin 1 and bin 2 at -10C
2) warmed up the camera from -10C to -5C, then wait 10 minutes to be sure its stable at the new temperature
3) Capture darks for 30s exposures @ bin 1 and bin 2 at -5C
4) Shutdown the cooler, wait 8 minutes and then close the camera
During step 2 at 02:48:13, the sequence started a 600s countdown to allow the cooler time to further stabilize after the temperature change. This sequence step took over half an hour to run, ending at 03:21:06! During running this countdown, the following warning showed up, which sounds relevant:
Info 03:17:33.036889 #32 =='.NET ThreadPool Worker' (New Thread)
Warning 03:17:33.040138 #32 Possible dispatcher overload. Background priority not run for 20.6s since 10:17:12 AM. Dispatcher queue length is 10, currently 1 in progress. in async Task SharpCap.UISwitcher+DispatcherWatchDog.MonitorDispatcher()
During 4, after shutting down the camera, the sequence started another 480s countdown to allow the cooler to come back to ambient before closing the camera. This countdown started at 04:23:36 and ended at 06:18:46!! At 04:41:57 a similar warning message to the above appeared.
The camera was in live view mode at this time. I ran some more tests when I got up in the morning when I saw this strange behavior in the sequence log. You can see the testing a 600s countdown starting at 08:14:12 in the log, with live view still on, and ended at 08:29:28. Not as bad - only 5 minutes too long. There were no dispatcher overload warnings. I reran this countdown test (it seems after then end of the attached log) with live view turned off, and it took exactly 10 minutes to run, as one would expect.
It looks like there is still a lot of debugging code present, so that is probably slowing things down during live-view capture. However, almost 2 hours to run a 480 second count down, with some dispatcher overload warnings looks suspect, so I thought I better report it.
I was running some python script testing earlier in the evening. I was just debugging some scripts to get and then change some camera control values and live stack conntrol values. Nothing fancy with modifying the interface or anything like that. I don't think I broke anything here...hopefully.
I started a sequence at 01:39:58 to capture darks at two temps with the following series of operations:
1) Capture darks for 30s exposures @ bin 1 and bin 2 at -10C
2) warmed up the camera from -10C to -5C, then wait 10 minutes to be sure its stable at the new temperature
3) Capture darks for 30s exposures @ bin 1 and bin 2 at -5C
4) Shutdown the cooler, wait 8 minutes and then close the camera
During step 2 at 02:48:13, the sequence started a 600s countdown to allow the cooler time to further stabilize after the temperature change. This sequence step took over half an hour to run, ending at 03:21:06! During running this countdown, the following warning showed up, which sounds relevant:
Info 03:17:33.036889 #32 =='.NET ThreadPool Worker' (New Thread)
Warning 03:17:33.040138 #32 Possible dispatcher overload. Background priority not run for 20.6s since 10:17:12 AM. Dispatcher queue length is 10, currently 1 in progress. in async Task SharpCap.UISwitcher+DispatcherWatchDog.MonitorDispatcher()
During 4, after shutting down the camera, the sequence started another 480s countdown to allow the cooler to come back to ambient before closing the camera. This countdown started at 04:23:36 and ended at 06:18:46!! At 04:41:57 a similar warning message to the above appeared.
The camera was in live view mode at this time. I ran some more tests when I got up in the morning when I saw this strange behavior in the sequence log. You can see the testing a 600s countdown starting at 08:14:12 in the log, with live view still on, and ended at 08:29:28. Not as bad - only 5 minutes too long. There were no dispatcher overload warnings. I reran this countdown test (it seems after then end of the attached log) with live view turned off, and it took exactly 10 minutes to run, as one would expect.
It looks like there is still a lot of debugging code present, so that is probably slowing things down during live-view capture. However, almost 2 hours to run a 480 second count down, with some dispatcher overload warnings looks suspect, so I thought I better report it.
I was running some python script testing earlier in the evening. I was just debugging some scripts to get and then change some camera control values and live stack conntrol values. Nothing fancy with modifying the interface or anything like that. I don't think I broke anything here...hopefully.