Garbage in logfiles

There’s still a lot of garbage in SGP log files after gear is powered off when SGP is running, would be great if this is fixed because log files can get pretty large just with this garbage.
Check this file
https://www.dropbox.com/s/969lwd7pbn4168h/sg_logfile_20190813215023.7z?dl=0

There’s still a lot of garbage that can be removed, only 10 000 of 59 000 lines is usable information.
sg_logfile_20191116000201.zip (140.5 KB)

I already removed a bunch of garbage, but not in that version… only in the most recent beta.

And to be clear, useful to us is probably defined differently from useful to you.

I don’t think it’s useful for anyone with almost 40 000 lines repetead of this:

[11/16/19 04:52:56.804][DEBUG] [CP Update Thread] ASCOM Rotator: Error in GetCurrentPosition : An existing connection was forcibly closed by the remote host (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: An existing connection was forcibly closed by the remote host
— End of inner exception stack trace —
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 243)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 284
at ASCOM.DriverAccess.Rotator.get_Position() in C:\ASCOM Build\Export\ASCOM.DriverAccess\Rotator.cs:line 123
at SequenceGenerator.AscomRotator.gp(Boolean A_0)
[11/16/19 04:52:57.828][DEBUG] [CP Update Thread] ASCOM Focuser: Error in GetCurrentPosition. : An existing connection was forcibly closed by the remote host
at System.RuntimeType.ForwardCallToInvokeMember(String memberName, BindingFlags flags, Object target, Int32[] aWrapperTypes, MessageData& msgData)
at ASCOM.DeviceInterface.IFocuserV2.get_Position()
at r8.get_Position()
at r2.h0(Boolean A_0)

Log files are really intended for the eyes of one person - the developer - well in this case that’s two people Ken and Jared.

The duty of users is simple, to provide the log file to the developers, nothing else.

Maybe some log messages seem excessive but even the excessiveness can give information.

Normally i would agree with you when it comes to log files, but i’ve seen many times other SGP users helping eachother finding problems in their settings, i’ve also been able to find several problems for my own sessions by looking at the log files.
This is time users spend so the developers can focus on developing SGP instead of helping users find what is sometimes just a simple fault in their setup

Don’t forget the autofocus log viewer either which is a really great help in finding better settings for autofocus, temperature compensation and filter offset…

@Xplode I understand what you are saying… the bottom line is that SGPro has a lot of logging in logical loops… meaning if a thing fails that we talk to every 2 seconds, there is going to be a failure every 2 seconds. I agree that we can add logic to detect this failure once and stop logging it, but it isn’t going to happen right now. What you are talking about is an exceptional situation… what I have cleaned up are logs that are more representative of sequence execution without equipment failure (equipment failure is really the only thing that will create a huge log like that).