Recorder Controls

[pljones]

The dirty hack of SIGUSR1/2 was never meant to be the permanent way of controlling the server recording feature. It worked locally for me but I did want to improve it. I've just never got around to it -- and then various people have developed work-arounds that effectively back-door your server to issue the SIGUSR1/2 commands, remaining not something you just want to be handing out.

I've obviously been brewing this over for a while and it's finally percollated out into something presentable.

You'll notice I start from the low level and work up to the UI -- having tried to start from the high-level of the Jamulus user... I hope everything joins up in the middle (but the UI probably needs more thinking time... and some mock ups).

---

As a Jamulus user, when a server offers recording
I want to be able to control participation in the recording

As a Jamulus server operator, when I make recording available
I want to control what facilities a user will have in controlling the server

As a Jamulus developer,
I want to ensure backwards compatibility for both client and server versions

---

Currently, when a server receives a new client connection:

• the server does not get told and cannot assume the client version
• the server sends vecChannels[iChID].CreateRecorderStateMes ( JamController.GetRecorderState() );

A client unable to process the Recorder State message silently ignores it

Proposal: a new Recorder Control State message

(Optionally) send this after the Recorder State message

• a client unable to process the Recorder Control State message silently ignores it, as any other unknown protocol message
• a capable client enables Recorder Control message support and processes the state message

Additionally propose a new Recorder Control Request message

• allows a capable client to control the server recorder

Recorder Control methods and meanings are:

• on-off: anyone can switch recording on or off, state then applies to all channels
• opt-in: default to channel not being recorded, channels that opt in are recorded
• opt-out: default to channel being recorded, channels that opt out are not recorded
• quorum-yes: no channels are recorded unless more than half the channels vote yes, in which case all channels are recorded
• quorum-no: all channels are recorded unless more than half the channels vote no, in which case no channels are recorded

Protocol:

• No change to existing recorder state message
• Two new "connected" recorder control messages:
  • .._RECORDER_CTRL_REQ:
    • single bit (bool): channel action, depends on recorder control method:
      • on-off: (true) turn on recorder; (false) turn off recorder
      • opt-in: (true) opt in; (false) opt out
      • opt-out: (true) opt out; (false) opt in
      • quorum-yes: (true) yes; (false) no
      • quorum-no: (true) no; (false) yes
  • .._RECORDER_CTRL_STATE:
    • one byte, method:
      0 - undefined (should never happen, internal)
      1 - on-off
      2 - opt-in
      3 - opt-out
      4 - quorum-yes
      5 - quorum-no
    • two bits per channel:
      • channel recording state: (true) recorded; (false) not recorded
      • channel recorder control state: (depends on method)
        • on-off: (true) most recent channel to change recorder state; (false) all others
        • opt-in: (true) opted in; (false) has not opted in
        • opt-out: (true) opted out; (false) has not opted out
        • quorum-yes: (true) voted yes; (false) did not vote yes
        • quorum-no: (true) voted no; (false) did not vote no

Server set up:

• obviously only for newer servers that have the support
• remove "--norecord" from the help (internally alias it to "--recorder-control off")
• add "--recorder-control <method>", where "<method>" is:
  • off: same as "--norecord":
    • do not start recorder on connect
    • use old statuses
    • no recorder control support
  • on: default (with --recording):
    • start recorder on connect
    • use old statuses
    • no recorder control support
  • on-off / opt-in / opt-out / quorum-yes / quorum-no:
    • as described above
    • recorder control support active

Server behaviour, if recorder control support active:

• server listens for .._RECORDER_CTRL_REQ from any channel
• server passes request to recorder
• recorder processes .._REQ according to method
• recorder emits control state changed in response to the .._REQ
• server listens for recorder control state changed
• server sends .._RECORDER_CTRL_STATE to all clients when
  • existing recorder state message gets sent (including new connection)
  • when recorder control state changes
• existing server-side signals work as follows:
  • when ignoring recorder control messages, work as now
  • when handling recorder control messages:
    • off means off
    • on means return to state set by control messages (...tricky?)

Currently the recorder does not worry about how many channels there are
so tracking "quorum" needs some further thinking.

Method	Recorder state on first client connect	Behaviour	.._REQ	.._STATE (channel)
on	on	existing default, no State messages sent, no Request support	n/a	n/a
off	off	existing state with --norecord, no State messages sent, no Request support	n/a	n/a
on-off	off	any channel can turn recorder on or off (no opt in/out)	true: turn on; false: turn off	true: changed recorder state last; false: others
opt-in	off	any channel can opt in, turning on the recorder; only opted in channels are recorded	true: opt in; false: opt out	true: opted in; false: not opted in
opt-out	on	any channel can opt out; opted out channels are not recorded	true: opt out; false: opt in	true: opted out; false: not opted out
quorum-yes	off	record when more than half the channels vote yes (no opt in/out)	true: vote yes; false: vote no	true: voted yes; false: did not vote yes
quorum-no	on	record unless more than half the channels vote no (no opt in/out)	true: vote no; false: vote yes	true: voted no; false: did not vote no

Server UI and preference should also be update...

Client side:

• (new) client listens for .._RECORDER_CTRL_STATE
  • Map the per-channel values from the .._RECORDER_CTRL_STATE message to the client channels
  • Headless support TBC
  • ClientUI:
    • Extend the server recording indicator to specify the method?
    • Get rid of "Chat" and "Settings" checkboxes
    • Move "Mute myself" below "Reverb" and "Input" meter
    • On the mixer, below the "channel has you muted" indicator, add:
      • a "channel is being recorded" indicator (simple solid disc, red)
    • a method-dependent indicator:
      • on-off: "channel set recorder state"
      • opt-in: "channel wants recorder on"
      • opt-out: "channel wants recorder off"
      • quorum-yes: "channel wants recorder on"
      • quorum-no: "channel wants recorder off"
• Method-dependent checkbox enabled when recorder control available (one of these):
  • on-off: "record": checked if this client turned the recorder on but unchecked if the recorder is turned off and then stays unchecked until checked
  • opt-in: "opt in": checked if this client has opted in on this server
    unchecked otherwise
  • opt-out: "opt out": checked if this client has opted out on this server
    unchecked otherwise
  • quorum-yes: "vote yes": checked to indicate client voted for recording
    unchecked otherwise
  • quorum-no: "vote no": checked to indicate client voted against recording
    unchecked otherwise
• client sends .._RECORD_CTRL_REQ when the checkbox is used
• Headless support TBC

Method	Label	Checked if this client	Unchecked if
on-off	"record"	turned the recorder on most recently and it is on	not
opt-in	"opt in"	opted in on this server	not
opt-out	"opt out"	opted out on this server	not
quorum-yes	"vote yes"	voted for recording	not
quorum-no	"vote no"	voted against recording	not

Storing client preferences:

• on-off: never stored: seen as disruptive behaviour otherwise
• opt-in/opt-out: stored per server
• quorum-yes/quorum-no: never stored: seen as "per band" and we don't understand that

[ann0see]

Hmm. Need to think a bit more about that. In general, I like this idea.
Being able to control the recording client side is a huge step forward.
However, this leads to a major usability question: how can the user who requested the recordings get them? For sure, we could use a web app. But that’s not integrated in Jamulus.

Putting many recording controls on the client might evoke the impression that the client does the recording. Certainly not what we want to evoke.
Tagging @jamulussoftware/designers for the UI/UX thing here.

Do we really complexity with the quorum feature? What’s the benefit?

Linking #1847 by @Rob-NY and #1789 by @cmdahoney here since they‘re somewhat related (although far)

[pljones]

The primary intent here was to give the client the ability to say "but I don't want to be recorded" and then I tried to see how flexible that could be made. Overall, it's only a next step. And, because the recorder is built in, I see that providing clients with control should be built in, whereas providing access to the recordings has never been available and, with this change, that's not changing. This is more like the "Mute/Solo" and "Mute myself" controls.