Stop/start recording when headless on Windows

[Andrew999999]

Is your feature request related to a problem? Please describe.

If jamulus server is started with e.g. Task Scheduler with no gui it is not possible to turn recording on/off. It is either on for the duration the server is running, or off. This mode of operation is used when the user wants to turn the server instance off/on remotely (e.g. when being hosted in AWS) and doesn't want to have to log in as a user each time to start the server.

Describe the solution you'd like
<! --A clear and concise description of what you want to happen. -->
Ability to remotely turn recording off/on on a jamulus server, preferably without having to log in to the Windows server hosting it - although I recognise that that is optional.

Describe alternatives you've considered

Settings file that is periodically read by Jamulus server - easy but will result in delay before recording starts. This would cause usability issues.
Inter-process communication from another application - more complex to code specific to Windows, but would provide instant control which would fit well with useability (e.g. "let's record the next song").
Control from a client - most complex, e.g. which client, but best from a UX perspective as no remote login to the server is required first.

Additional context

A basic capability is available via SIGNIT for linux-hosted servers. But SIGINT is not supported on Windows.

[ann0see]

I think the linux headless build supports this with SIGUSR1 or SIGUSR2 not sure if Windows can send these commands

[Andrew999999]

SIGUSR1 and 2 aren't supported on Windows. Other inter-process communications methods are available on Windows.

[hoffie]

SIGUSR1 and 2 aren't supported on Windows. Other inter-process communications methods are available on Windows.

Right. Can you detail what methods would be common/useful on Windows in this case?

[Andrew999999]

SIGUSR1 and 2 aren't supported on Windows. Other inter-process communications methods are available on Windows.

Right. Can you detail what methods would be common/useful on Windows in this case?

1. Settings file that is periodically read by Jamulus server - very easy to implement but will probably result in delay before recording starts. This would cause usability issues depending on polling period. However given the additional work to code inter-process communication this might be the best pragmatic solution.
2. Inter-process communication from another application - more complex to code specific to Windows, but would provide instant control which would fit well with usability (e.g. "let's record the next song").
3. Control from a client - most complex, e.g. which client, but best from a UX perspective as no remote login to the server is required first.

This article discusses various mechanisms in Windows for dealing with the various types of UNIX messages. http://www.zemris.fer.hr/~leonardo/os/math/labosi/pripreme/upute/misc/Unix2Win.htm

For SIGUSR1/2 messages it suggests using SendMessage() - although this is asynchronous, so PostMessage() might be better. The function would need to be invoked from a second application or a PowerShell script e.g. as here https://stackoverflow.com/questions/56078270/use-powershell-to-send-message-to-a-window-control

[pljones]

The PowerShell script option sounds feasible. The existing signal handling code is messy and platform-specific anyway -- introducing proper PostMessage() support would probably be very useful.

Another option, of course, is run the server on Linux ;).

I have a Windows shortcut that just runs something like systemctl kill -s SIGUSR1 jamulus using ssh, for controlling my server. systemctl knows how to send a signal to the named service.

[Andrew999999]

Having spent time researching, optimising and testing linux vs Windows servers for Jamulus at the start of COVID, in summary my conclusion was that there was no discernable difference in performance or cost between the two, given identical VM specifications, and using Ubuntu 18.04 vs Windows Server 2019, and as compared with the overall performance of the client/server connection. There might be 5% difference in favour of linux purely comparing the servers, but this became immaterial when compared with e.g. variability between different ISPs or home networking and audio equipment.

Based on this, and given that it is much less time consuming to maintain Jamulus on a Windows VM, particularly with the multiple private servers I use, I've adopted a Windows-based strategy. I understand that people who are mostly familiar with linux might prefer a different approach - but that isn't me!

With that in mind, I'm trying to simplify remote management as much as possible - on the Windows platform. Hence my pursuit of functionality for headless Windows servers. My aim is to be able to remotely turn a Jamulus Windows instance on or off, e.g. via an AWS EC2 Console, and for the Jamulus server to function fully, move recording files to a local PC for final production etc. I can then automate all that to minimise AWS utilisation charges. I've achieved all that - except for enabling/disabling recording.

[ann0see]

Not a windows expert, but I assume, you could at least compile a jamulus headless server for windows too. I‘ll now unsubscribe from this.

[gilgongo]

@Andrew999999 It seems like there may be a solution to this emerging, but if it's OK I'll move this to a Discussion until we agree on a defined action that we can add to the backlog.

[pljones]

This should be addressed by (something like) #2006 or #1975.