Current SDR# does not work headlessly


Jukka / OH2BUA
 

I have been using SDR# version 1828 (and tens of earlier versions).

I mostly use it non-interactively, started by Windows Task Manager. The only plugin i'm using is AutoStartRadio.

Now I updated to version 1854. It doesn't work any more when started by Windows Task Manager. Crashes immediately at start. This happens every time.

CRASH.TXT says:

Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application.
at <Unknown>.Form.ShowDialog  (IL offset: 0xa3)
at <Unknown>.Form.ShowDialog  (IL offset: 0x0)
at <Unknown>.<>c.<OpenSplash>b__3_0  (IL offset: 0xa)
at <Unknown>.QueueUserWorkItemCallbackDefaultContext.Execute  (IL offset: 0x14)
at <Unknown>.ThreadPoolWorkQueue.Dispatch  (IL offset: 0x0)
at <Unknown>.WorkerThread.WorkerThreadStart  (IL offset: 0x67)
at <Unknown>.Thread.StartCallback  (IL offset: 0xe)

As a display i use RDP remote connection only, and SDR# works over it fully ok.

Environment: Windows 10 Pro 21H2 x64, Intel NUC i7-889U with Intel Iris 950 onboard graphics (no display attached). Airspy HF+D and RTL-SDR blog v.3 rx-hw.

I would be very happy to hear if there is any workaround for this.

73, Jukka


prog
 

On Sat, Jan 22, 2022 at 11:50 AM, Jukka / OH2BUA wrote:
The only plugin i'm using is AutoStartRadio.
Thank you for documenting another case of hacks that shouldnt exist in the first place.

Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application.
Here's your "workaround". Happy hacking. 


Jukka / OH2BUA
 

Ok, thank you for your friendly and co-operative reply.

73, Jukka


prog
 

On Sat, Jan 22, 2022 at 12:47 PM, Jukka / OH2BUA wrote:
Ok, thank you for your friendly and co-operative reply.
No one likes spending their week-ends destroying the quality of a huge code base for the sake of friendliness or cooperation. 


Peter Jönsson
 

Hello
I have done some tests with this and the AutoStartRadio plugin works perfectly on my system.
Receiver is AirSpy HF+ Discovery. SDR Studio version 1854. Latest AutoStartRadio dll version 1.0.0.2 downloaded from https://github.com/jklnz/SDRSharpPlugins/releases
I'm guessing there's something wrong with your SDR configuration.

Peter

Windows 11 Pro
Version 21H2
Installerad ‎2021-‎10-‎12
OS-version 22000.438
Gränssnitt Gränssnittspaket för Windows-funktioner 1000.22000.438.0

Enhetsnamn Peters-Dator
Processor Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz   3.70 GHz
Installerat RAM-minne 16,0 GB
Enhets-ID
Produkt-ID
Systemtyp 64-bitars operativsystem, x64-baserad processor


prog
 

On Sat, Jan 22, 2022 at 01:41 PM, Peter Jönsson wrote:
I'm guessing there's something wrong with your SDR configuration.
Starting a GUI application as a service, for example? 


Peter Jönsson
 

The only thing I have done is to download the dll and place it in the plugin folder. Created a shortcut from SDRSharp.exe to autostart.
When the computer starts up, SDR Studio starts after a few seconds, five seconds later HF + Discovery starts receiving.

Peter


Jukka / OH2BUA
 

Peter,

AutoStartRadio is not related into the problem. It also happens without it. I only mentioned it as a part of my environment. As SDR# doesn't do much without autostart, non-interactively.

Let's not disturb his weekend more about this.

73, Jukka


prog
 

On Sat, Jan 22, 2022 at 02:08 PM, Jukka / OH2BUA wrote:
AutoStartRadio is not related into the problem. It also happens without it.
When the app is expecting some interaction via some dialog window, the OS will terminate it if running as a service. This also applies to the splash screen which asks you to wait while loading all the components. That's what your error message says. The splash screen error can be ignored/solved/hacked but any other interactions like the file dialog, or any dialog from any plugin, can crash the process anyway. Ignoring these errors will make the whole code base opaque and unreliable. There is a huge difference between keeping a hack alive and building for the future.
You may have a better luck with this purpose built command line utility: https://github.com/jj1bdx/airspy-fmradion It may not have all the fancy bells and whistles, but it will most probably be more adequate.


Jukka / OH2BUA
 

I'll rollback. Case closed for me. 73, Jukka


jdow
 

On 20220122 04:45:00, prog wrote:
On Sat, Jan 22, 2022 at 01:41 PM, Peter Jönsson wrote:
I'm guessing there's something wrong with your SDR configuration.
Starting a GUI application as a service, for example?

That is perfectly OK if you make very sure that a user is logged in before the GUI appears. The Windows ntp (network time protocol) tool I use works that way. I've copied the concepts and use them fairly often. But the idea of SDRSharp as a service is a little boggling.

Putting it into startup should work if it has or grows a command prompt option "run" or "autostart" that starts SDRSharp a second or two after it's opened and has its head together.

{^_^}


Jukka / OH2BUA
 

Hi jdow,

The reason i'd need to run it a separate session is a bit complex:

I need to run it all the time whether i'm logged in or not.

I need it to feed audio into a virtual audio cable and further onwards to wsjt-x.

For interactive use, i use MS-RDP. It handles audio devices somehow strangely: When connected, RDP cuts off standard audio devices and replaces them by just one device "RDP Audio". So, it is impossible to have for example a SDR#=>WSJT-X audio link and at a same time listen something remotely. In the SAME user session. In a separate concurrent session it is ok.

(Why RDP? Why not teamviewer or anydesk or...? I like it to be only two-party, not three-party solution, and have a 1:1 pixel-perfect desktop.)

No, i'm not forcing it to run as a service.

It is started like this:
start "SDRsharp" /D "C:\Program Files (x86)\SDRSharp\" "C:\Program Files (x86)\SDRSharp\SDRSharp.exe"
and is listed by Windows as a process, not as a service.

But hey, 1854 does not work in that context, but 1828 works ok. So I'm a "happy hacker". Yep, my happiness can't be very simply stomped into to the floor with just arrogant and aggressive "support".

73, Jukka


jdow
 

Learn to use RDP. Click on "Show Options" on its connect dialog lower left BEFORE you connect. Note the "Local Resources" tab. See if one of the "Remote audio" modes does what you need. Also check "Local devices and resources" and its "More..." button. That might give you an easy solution. OTOH - if it works don't fix it. (I've had a couple "TeamViewer" sort of programs become expensive after long periods of being free.)

{^_^}

On 20220123 03:49:12, Jukka / OH2BUA wrote:
Hi jdow,

The reason i'd need to run it a separate session is a bit complex:

I need to run it all the time whether i'm logged in or not.

I need it to feed audio into a virtual audio cable and further onwards to wsjt-x.

For interactive use, i use MS-RDP. It handles audio devices somehow strangely: When connected, RDP cuts off standard audio devices and replaces them by just one device "RDP Audio". So, it is impossible to have for example a SDR#=>WSJT-X audio link and at a same time listen something remotely. In the SAME user session. In a separate concurrent session it is ok.

(Why RDP? Why not teamviewer or anydesk or...? I like it to be only two-party, not three-party solution, and have a 1:1 pixel-perfect desktop.)

No, i'm not forcing it to run as a service.

It is started like this:
start "SDRsharp" /D "C:\Program Files (x86)\SDRSharp\" "C:\Program Files (x86)\SDRSharp\SDRSharp.exe"
and is listed by Windows as a process, not as a service.

But hey, 1854 does not work in that context, but 1828 works ok. So I'm a "happy hacker". Yep, my happiness can't be very simply stomped into to the floor with just arrogant and aggressive "support".

73, Jukka


Jukka / OH2BUA
 

jdow,

I do have a black belt in using of RDP, seriously. If you need to learn more about it, just ask me.

I know how those (pretty weird) RDP audio options walk. And what they do mean regarding server-side audio device availability.

Yep, play here, don't play at all, play there...

RDP is not a part of the problem - and reconfiguring it is not a solution. I just mentioned it as the way I operate my remote site.

73, Jukka


jdow
 

OK - it was a thought when you mentioned it had unpleasant quirks.

{^_^}

On 20220123 11:54:40, Jukka / OH2BUA wrote:
jdow,

I do have a black belt in using of RDP, seriously. If you need to learn more about it, just ask me.

I know how those (pretty weird) RDP audio options walk. And what they do mean regarding server-side audio device availability.

Yep, play here, don't play at all, play there...

RDP is not a part of the problem - and reconfiguring it is not a solution. I just mentioned it as the way I operate my remote site.

73, Jukka