Massive Log Files


#1

Last night I was having a number of issues with SGP (and PHD2 and Atik drivers) so I decided to see if I could find any info about where the issue was occuring so I turned to the log files.

Over a 5 minute period, one log file generated was 160MB.

From line 228 to line 1107061 of the file the same error messages were repeated ad infinitum.

I believe the root cause of why the error is generated in the first place is to do with ATiK ascom drivers kicking the bucket, but the way SGP handled the error seems a bit… excessive.


#2

I also am seeing some log file bloat. In my latest shot at getting plate solving to work for me, my log file for 130 minutes of trying to successfully center on 5 different objects, 2 worked perfectly, 3 failed on the final validation solve.
In trying to see what the problem might be I was studying the log, which was 2.3 million bytes in length. About 2/3 of it was the following error, repeated a few up to 50 or more times, at 1 second intervals:
[10/6/2014 10:45:44 PM] [DEBUG] [CP Update Thread] ASCOM Focuser: Error in GetCurrentPosition. : The scope is not connected
at ASCOM.Interface.IFocuser.get_Position()
at SequenceGenerator.SafeFocuser.get_Position()
at au.GetCurrentPosition(Boolean force)
This made following the useful log entries very difficult. I finally resorted to deleting all these (very time consuming) just so I could see what was really happening.
The real mystery to me is, I did not request any automatic focusing anywhere in any of the sequences. …Well, I don’t think so.
I had “Use auto focus” checked on the Focus tab of Control Panel, but under Set where you provide the details of how the autofocus should operate, none of the Choose Frequency boxes were checked. Is it reasonable to expect that this would inform SGP that no auto focus is to be done, and therefore no focus error messages would appear in the log? Or does it just perform 1 autofocus sequence?
Even so, can the error log processing routines be smart enough to only put out 1 copy of a given error?
Ideally, (1) it could add the current error message (2) if more of the same error message come, it would simply add a line like “…more of this error”.


#3

While it’s unfortunate that the log is bloating this is an error case which we likely won’t resolve. Essentially your focuser stopped responding to SGP. The real issue would be figuring out why your focuser stopped responding.

I would recommend treating the source of the error rather than wanting to hide it.

Thanks,
Jared


#4

From a look at the log file bloat doesn’t seem an unreasonable description.

Something has gone wrong, SGP logs the error and retries in a tight loop, the error keeps reoccurring and no more information seems to be generated after that, just bloat. A better option for handling errors that you can’t recover from is to log it and break out of the loop.

From a look at the log that was posted there’s a problem reported by the Atik Camera driver in the GetSetCCDTemperature call:

[21/07/2014 9:16:50 PM] [DEBUG] [CP Update Thread] ASCOM Camera: Error in GetCoolerTemp. : CLR has been disabled due to unrecoverable error. (Exception from HRESULT: 0x80131023)
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)
at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, CultureInfo culture)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 266
at ASCOM.DriverAccess.Camera.get_CanSetCCDTemperature() in c:\ASCOM Build\Export\ASCOM.DriverAccess\Camera.cs:line 240
at ac.GetCoolerTemp()

That seems to be repeated interminably. It looks pretty low level, there’s no reason why the CLR should be disabled by an error in the ASCOM driver and pretty unlikely that this error would be generated by a driver that’s successfully connected to a camera.

If it’s reproducible try turning error logging on in the ASCOM ATIK driver and reproduce the error. Post the ASCOM log as well as the SGP error. The ATIK log is more likely to give detail of what’s happening.

The first thing with fixing errors is to find out what is happening.

Chris


#5

Sorry you find them too large. That said, we do not design log files to be
user consumable. They are for developer use when debugging.


#6

Also… SGPro’s request to get your focusers position has nothing to do
with auto focus.


www.mainsequencesoftware.com