2.0.927.0 random crash

[Trevor Smithers]

I'm seeing a random crash on one of my machines (Win 10/64) running 2.0.927.0.

Spark will run for say 2 hours or so and just disappear, no error messages or anything, it just closes down. Restarting Spark and all is well - until the next time.

Error log

19/11/2022 11:20:32 v2.0.927.0
Main UnhandledException
Object reference not set to an instance of an object.
Avalonia.Base
Avalonia.Collections.Pooled.PooledList`1[T] GetAlive(System.Func`1[Avalonia.Collections.Pooled.PooledList`1[T]])
   at Avalonia.Utilities.WeakHashList`1.GetAlive(Func`1 ) in /_/src/Avalonia.Base/Utilities/WeakHashList.cs:line 239
   at Avalonia.Utilities.WeakEvent`2.Subscription.OnEvent(Object , TEventArgs) in /_/src/Avalonia.Base/Utilities/WeakEvent.cs:line 168
   at System.Reactive.AnonymousSafeObserver`1.OnNext(T) in /_/Rx.NET/Source/src/System.Reactive/AnonymousSafeObserver.cs:line 54
   at System.Reactive.Linq.ObservableImpl.SelectMany`2.EnumerableSelector._.OnNext(TSource) in /_/Rx.NET/Source/src/System.Reactive/Linq/Observable/SelectMany.cs:line 1379
   at System.Reactive.Linq.ObservableImpl.Buffer`2.Boundaries._.BufferClosingObserver.OnNext(TBufferClosing) in /_/Rx.NET/Source/src/System.Reactive/Linq/Observable/Buffer.cs:line 829
   at System.Reactive.Linq.ObservableImpl.Merge`1.Observables._.InnerObserver.OnNext(TSource) in /_/Rx.NET/Source/src/System.Reactive/Linq/Observable/Merge.cs:line 240
   at System.Reactive.Subjects.Subject`1.OnNext(T) in /_/Rx.NET/Source/src/System.Reactive/Subjects/Subject.cs:line 141
   at ReactiveUI.IReactiveObjectExtensions.ExtensionState`1.RaisePropertyChanged(String) in /_/src/ReactiveUI/ReactiveObject/IReactiveObjectExtensions.cs:line 397
   at ReactiveUI.IReactiveObjectExtensions.RaisingPropertyChanged[TSender](TSender, String) in /_/src/ReactiveUI/ReactiveObject/IReactiveObjectExtensions.cs:line 240
   at ReactiveUI.IReactiveObjectExtensions.RaiseAndSetIfChanged[TObj,TRet](TObj, TRet&, TRet, String ) in /_/src/ReactiveUI/ReactiveObject/IReactiveObjectExtensions.cs:line 121
   at radio.PskReporter.process(Object)
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()

73 Trevor  G0KTN

--   

[ahop...@googlemail.com]

Hi Trevor,

thanks for that, sorry you have become a tester for the latest under the cover tweaks by me and the Avalonia team but hopefully it will up end producing a stable 2.1 release. Should be a simple fix.

73 Alan M0NNB

[ahop...@googlemail.com]

Hi Trevor and all,

this https://www.sparksdr.com/download/SparkSDR.2.0.928.win64.zip should fix the crash, it also tweaks the PI4 snr and allows uploads of PI4 to Pskrporter.

73 Alan M0NNB

[Trevor Smithers]

2.0.928 has been running for 24hrs or so and appears quite stable. 

PI4 snr has improved to the point that there is very little difference between Spark and PI-RX

Spot counter and psk uploads work correctly.

However ......

I have 2 machines running 2.0.928 (Win10/64)

(1)  I5-8600k running HL2 (10 bands) plus 3 SDRplays

(2)  AMD Ryzen 7 4700u running 2 SDRplays

On the I5 I'm seeing a spectrum pause once per minute on the 25 second mark. The spectrum will stop for about 1 second and then resume.

Task Manager shows a cpu spike to 100% for a couple of seconds or so before returning to around 30/50%.

I assume that Spark is processing data at this point, but I haven't noticed the spectrum pause behaviour on previous versions.

The AMD machine does not show this problem, however it's not so heavily loaded as the I5

73  Trevor  G0KTN

[ahop...@googlemail.com]

Hi Trevor,

sounds like we are getting there.  This has a few tweaks that might reduce the PI4 decode cpu use but I doubt will make a big difference https://www.sparksdr.com/download/SparkSDR.2.0.929.win64.zip

73 Alan M0NNB

[Trevor Smithers]

2.0.929

Alan

Well, whatever you did has actually made a difference. The spectrum pause is still there but the recovery time has reduced considerably - you now need to be looking for it to notice it.
Now seeing an odd cpu spike to 100% every so often which is more consistent with normal system processes etc

73  Trevor  G0KTN