V3.1 Freezing After The 13Th Exposure

[Jim]

I have just had BYE 3.1 freeze for the second time as it was about to start its 14th expose as it downloads the 13th.

 

I had this happen as I was taking lights and it has just happened again whilst taking darks.

 

I can see no cause for the freeze as the camera seems to be OK and whilst BYE was frozen guiding continued uninterrupted, guide camera working off one USB lead back to first USB hub in laptop (USB 3), 650D and mount on second USB lead to second USB hub in laptop (USB 2).

 

I have not seen this behaviour before and this is the first time I have used 3.1 apart from on my desk.

 

I simply force stop BYE and restart and it all carries on as if nothing happened!

 

I will continue with the nights plans, but with no more than 12 exposures in a block.

 

Jim

 

Just happened twice more after the first exposure after re-starting. Going to reboot the PC to see if this allows me to continue for the night.

 

Rebooted laptop, failed again and froze during first download. Reverting to 3.1 RC05 to see if I can continue for the night ;^))

[Jim]

Working again in 3.1, changed the subject name from M81 to M81A and all working again! Would not work to the original subject name (and therefore save directory name) with 3.1 RC05 or 3.0.3.

 

Was about to revert to saving on camera but decided to try a different subject name and subsequent save folder name and its now working again!

 

Phew, I'm hoping to have a first attempt at M78 later tonight (this morning), so would have been a bit disappointed if I had not been able to continue. 

 

Jim

[admin]

Hi Jim,

 

Did you get an error message?  Freezes are rare, it is usually another error that caused the app to stop the session plan.

 

Send me the 3.1 log file when it failed please and I should be able decipher what happened.

 

Regards,

[Jim]

Guylain,

 

Watching what was going on last night my laptop was starting indexing and also a Windows Defender scan which was causing BYE to freeze, this happened every time it saved an exposure (360 secs) unless I went and jogged the mouse and pocked around between the various windows, which aborted the Windows OS and Defender housekeeping activities allowing BYE to save the frame without interruption. I frequently have Stellarium running, but not last night, and I'm wondering if this is sufficient for Windows to hold off its housekeeping routines. When windows was doing its housekeeping and BYE was trying to save the frames the hard drive was running at 100% as were the 4 CPUs. Obviously my intervention caused the housekeeping processes to cease, though BYE would not recover (waited about 5 mins a couple of times).

 

When BYE was frozen there was a second window open in the background but I could not select and display it (I.e. on the task bar there was 2 windows being indicated).

 

This evening I have Stellarium running along with Chrome and even a quick burst of PixInsight and everything looks to be behaving itself! 

 

My laptop is a quad core Samsung with 4 GB of ram running windows 8.1.

 

I will send the logs from last night where BYE froze as they may give a clue as to how it may be possible for BYE to indicate it is busy so that Windows doesn't start its housekeeping, which Stellarium seems to be able to do (whether by design or coincidence I have no idea!).

 

Regards

 

Jim

[s3igell]

Perhaps you should consider changing the Scheduler Settings for these various Windows Defender and other Background Tasks from their usual Midnight starts to something more conducive to AP Imaging such as 6AM.

[admin]

Thanks, I got the log files.  I will look closely around that time to see if it played a role... it most likely did.

 

Regards,

[Jim]

Thanks Si3gell, I have configured Defender's various tasks not to start until after a period of 30 mins of inactivity, which should be long enough as I probably check tracking, frames, etc. more frequently than that.

 

I have also disabled SuperFetch as it looked to be this that was driving my hard drive to 100% activity after a few minutes of inactivity. Looking on the net this seems like quite a common issue and may others have had to disable this process to prevent their PC's from becoming bogged down by this process whilst the work they are doing fails or becomes sluggish!

 

Since doing the above, no more CPU and hard drive running at 100%, just barely got to about 50% on CPU and less than 10% on hard drive with BYE, PHD, Stellarium and all the other myriad tasks that Windows has going on. 

 

Guylain,

 

I'm still getting many:

 

2014-12-30 17:59:22,912 [OnStateEventHandler] DEBUG - OnStateEventHandler Fired! (inEvent=795), inParameter=0)

 

events being recorded.

 

Do you have any further ideas as to what this might be?

 

I have looked through the logs on my laptop and as I said last night it appears in my logs going back about 18 months or so (from the first log file I have). Checking on my desk top the more recent logs on their also have this entry. (Note to self, if BYE is open and its log file is opened in another application when telling BYE to connect to camera it causes BYE to crash and windows to close it! Probably not unexpected behaviour).

 

On my PC the first log file I have dates back to 09 2012, BYE 2.0.7 and the DEBUG message is not present. Nor in 10 2012 under BYE 2.0.8. On the 11th March 2013 in the log for BYE (version not known as it just says "BackyardEOS started!" without a version number there are no DEBUG entries of this type but on the 4th of April 2013 there are more than 100 entries, again no BYE version given. I think it was around this time that you and I were looking into issues around the 5X zoom on the 650D on the soon to be released new version (at the time) of BYE and I was beta testing BYE 2.1 various betas against the 650D for you. (Found the reference in my email archives). It looks like this issue started (but was not observed) between a couple of the betas that we were testing.

 

It looks like this version http://www.binaryrivers.com/download/BackyardEOSv210-PreBetaTest-3.zip worked OK  without these DEBUG messages but when I then changed to BackyardEOS-v210-BETA01.zip at the beginning of April the issue started and looks to haver been there since.

 

Don't know if this helps to identify what is causing these events?

 

Regards

 

Jim

[Jim]

Guylain,

 

Have you had any opportunity to look into this any further?

 

Regards

 

Jim

[admin]

Hi Jim,

 

Yes, and I'm not finding anything

 

Can you try adding a 2 second pause between exposures and see it it makes a difference.  The camera is reporting that it is in a busy state and the 2 second pause may be just enough.  It is worth a try.

 

Keep me posted.

[admin]

Thanks Jim for reporting back.  I'll continue to dig into the log files.

[Jim]

Guylain,

 

Just got myself a new laptop and tried 10 x exposures with no pause followed by 10 exposures with a 2 second pause, no [OnStateEventHandler] DEBUG - OnStateEventHandler Fired! (inEvent=795), inParameter=0) anywhere I can see!

 

Though, one thing that does come to mind is that my old laptop and my desktop have AMD (4 core and 8 core respectively) processors whereas my new laptop is an Intel i7, could this have anything to do with these DEBUG messages? 

 

Log file attached from the test run I just performed, there are a couple of DEBUG messages but they are not related to this issue.

 

Regards

 

Jim

 

 

 

logfile-20150117-17h34m47s247-backgroundworker-5628-2015-01-17.txt

[Jim]

Guy,

 

Further to my last reply, I repeated the test on my desktop using BYE 3.1.2 and again no DEBUG messages related to this issue, see attached log file.

 

BYE 3.1.2 - logfile-20150117-18h04m06s157-backgroundworker-7820-2015-01-17.txt

 

I then re-loaded BYE 3.0.3 on to my desktop and it is full of these DEBUG messages, again see attached log file.

 

BYE 3.0.3 - logfile-20150117-18h19m55s533-7744-2015-01-17.txt

 

One thing I did notice is that both on my laptop and desktop running 3.1.2 the queue count (number of frames waiting for the background process to complete) never went above 1 from beginning to end of the run, whereas under 3.0.3 on the desktop the queue count was up to 8 by the 20th exposure (up to to 6 by the 7 or 8 exposure) !

 

Don't know if this helps to identify what is going on.

 

Regards

 

Jim

 

 

 

[dts350z]

That's because in 3.0.x stuff is single threaded. Expected behavior.

[Jim]

dts350z, the origin of this thread was for 3.1.0 / 3.1.1 which I believe are not single thread!

 

Jim

[admin]

Guy,

 

Further to my last reply, I repeated the test on my desktop using BYE 3.1.2 and again no DEBUG messages related to this issue, see attached log file.

 

BYE 3.1.2 - logfile-20150117-18h04m06s157-backgroundworker-7820-2015-01-17.txt

 

I then re-loaded BYE 3.0.3 on to my desktop and it is full of these DEBUG messages, again see attached log file.

 

BYE 3.0.3 - logfile-20150117-18h19m55s533-7744-2015-01-17.txt

 

One thing I did notice is that both on my laptop and desktop running 3.1.2 the queue count (number of frames waiting for the background process to complete) never went above 1 from beginning to end of the run, whereas under 3.0.3 on the desktop the queue count was up to 8 by the 20th exposure (up to to 6 by the 7 or 8 exposure) !

 

Don't know if this helps to identify what is going on.

 

Regards

 

Jim

 

Hi Jim you are comparing apples and oranges... the backgroundserver log contains no camera info because it does not connect to the camera

 

Regards,

[admin]

dts350z, the origin of this thread was for 3.1.0 / 3.1.1 which I believe are not single thread!

 

Jim

 

He meant the application runs in a single cpu thread, not this threaded conversation

 

Regards,

[admin]

Jim, just a a single test for me.

 

On the computer where it eventually freezes... add a 2 second pause between images and run a session... does it freeze eventually or does it not?  Forget about the content of the log file for now, the more I think about it the more I believe the "OnStateEventHandler" is not related and a non issue.

 

Just run the test with 2 second pause and report back on those result please.

 

Regards,

[Jim]

Unfortunately the laptop where I had the freeze problem is currently being rebuilt for my wife as she is inheriting it from me ;^))

 

When I have finished loading the Gbytes of windows upgrades, all her craft software, etc. I will load BYE and try a few test runs, hopefully later this evening.

 

Regards

 

Jim

[Jim]

Guylain,

 

Loaded BYE 3.1.0 and then 3.1.2 on the laptop and have done 10 runs of 20 x 20s frames with and without a pause (5 on each version of BYE), no issues. I 'guess' a clean BYE install on a clean Windows install has cured the problem.

 

I hadn't noticed that the 3.1.2 logfile I posted earlier was a backgroundworker file. I don't know what is happening on my desktop but it doesn't look to be saving logfiles for 3.1.2 (I have searched 'This PC' and can find all the background logs but no application log files for this evening on any of my drives (loads of old ones). I have removed BYE and re-installed it, rebooted my PC and still can't find any logfiles on the desktop, they are on my laptop so its not a BYE issue!

 

Sorry to have wasted your time.

 

(Debug messages are still there on both this laptop and (when I looked in the correct logfile) on my new laptop.)

 

Jim

[Jim]

Just installed BYE in a different folder and logfiles are now appearing correctly on my desktop PC.

 

Jim