Jamulus: Feature proposals: max recording time

[pljones]

Whilst it's now possibly to kick off a new recording from the GUI and command line, unless you have server side access, there's no way to get a new recording. So when you're on a server with recording, you'd have to arrange to leave to make sure a new recording gets taken.

I was thinking that it might be useful to add one or two other features. The first would be a "max recording time", which would effectively be like sending SIGUSR1 (start new recording) after the recorder had been running for a set period of time. It's a minimal change just to ensure (a) that recordings don't get stupidly large and (b) do get saved at least at some point. This is easy enough to do (as each frame can check how long the recorder has been running and send the signal if needed).

I was also thinking, less concretely, about having some kind of chat text parser, similarly to how the NINJAM server has chat commands. This would allow anyone in the jam to say "!recorder new" to trigger a new recording. If adding "!recorder off/on", these would only apply until the server went to idle, when it would revert to its "command line" state (i.e. it would need to be another layer on top of the existing enable/disable state).

I'm quite keen on the timer idea. I'm wondering if others would find the commands useful.

[chrisrimple]

I would love a time limit and/or an easy way to end a recording. I own the server but have historically had to wait for everyone to leave so that I can download a recording after a band rehearsal - I’d rather have them force end after a time period or make it easier to end them with logging into the server.

[ann0see]

Yeah, chat text parsing in general would be great (I implemented chat commands in my fork (eduTools branch)).

[pljones]

OK, once the segfault fix and maybe after the float changes, I'll get onto this.

@ann0see, are your chat changes of general use - i.e. worth sorting out for a pull request?

[ann0see]

No. They aren't. They are (and were) mainly a test to implement some kind of waiting room feature. Of course, code can be used, although I doubt that my coding quality in C++ is good enough ;-).

See https://github.com/ann0see/jamulus/blob/abc938b3a7aaeb1118ba879576b7bc37441540d3/src/server.cpp#L1424

[chrisrimple]

FWIW, I've figured out how to use:

systemctl kill -s SIGUSR1 jamulus
systemctl kill -s SIGUSR2 jamulus

But still think it would be handy to have a way to execute SIGUSR1 from the client while connected to the server. I wonder if there's a security issue, in that anyone could execute that command? Probably should not allow SIGUSR2 from the client. Or can we authenticate the client user with server password (which should only be available to the owner)?

[WolfganP]

FWIW, I've figured out how to use:

systemctl kill -s SIGUSR1 jamulus
systemctl kill -s SIGUSR2 jamulus

But still think it would be handy to have a way to execute SIGUSR1 from the client while connected to the server. I wonder if there's a security issue, in that anyone could execute that command? Probably should not allow SIGUSR2 from the client. Or can we authenticate the client user with server password (which should only be available to the owner)?

Jamulus isn't based in the concept of administrator/plain user, so anything that implies remote administration of the server via the client program, will be open to anyone connected to use, abuse or click in error...
Recording being a server functionality, it makes sense (to me) that it may be operated by whoever has access to the server (being local or remote). If you want to somehow make it easier to operate the recordings, you may alias the commands in your terminal, or maybe use a macro on your ssh/telnet/terminal client.

[pljones]

OK, timer seems to be working.

Command line:

peter@fs-peter:~/git/Jamulus-wip$ ./Jamulus -s -n -p 55850 -R /tmp/recording --maxrecordtime 3
- server mode chosen
- no GUI mode chosen
- selected port number: 55850
- recording directory name: /tmp/recording
- each recording session will restart after 3 minutes
Recording state enabled
 *** Jamulus, Version 3.5.11git
 *** Internet Jam Session Software
 *** Released under the GNU General Public License (GPL)
2020-09-28 18:43:12, 192.168.1.5, connected (1)
Session RPP: "/tmp/recording/Jam-20200928-174312269/Jam-20200928-174312269.rpp"
Session LOF: "/tmp/recording/Jam-20200928-174312269/Jam-20200928-174312269.lof"
Session RPP: "/tmp/recording/Jam-20200928-174612316/Jam-20200928-174612316.rpp"
Session LOF: "/tmp/recording/Jam-20200928-174612316/Jam-20200928-174612316.lof"
2020-09-28 18:50:05,, server idling -------------------------------------
Session RPP: "/tmp/recording/Jam-20200928-174912316/Jam-20200928-174912316.rpp"
Session LOF: "/tmp/recording/Jam-20200928-174912316/Jam-20200928-174912316.lof"

Passing the command line option to the GUI server gets:

... and it's remembered the value when restarting without the command line option and uses the saved value.

I'll clean up the patch a bit and get a pull request for this bit done.

[corrados]

Jamulus isn't based in the concept of administrator/plain user, so anything that implies remote administration of the server via the client program, will be open to anyone connected to use, abuse or click in error

I totally agree.

OK, timer seems to be working.

Hm, that looks very confusing to me. "Max. Record Time" sounds to like no recording can be longer than that time. But that is not true. It simply creates a new file but the recording continues but just in a new file.

What would be a meaningful value of that new parameter? I guesss something in the order of several songs. It would not make sense to make it one song long since you would most probably not get the correct beginning or end of the song. So I guess a meaningful value would be something like 10-15 minutes, right? Why not hard code such a value in Jamulus so that we do not need any command line/GUI parameter which just confuses the Jamulus server operators?

[chrisrimple]

Instead of "Max Record Time", I think "Default Record Length" is a better title. As a server operator, I like being able to set it for 60 min, 90 min, and other values depending on the planned length of my band's rehearsal. If it were only 15 min, I'd end up with 4-6 recording folders that I would then need to merge to create a single MP3 of the rehearsal, which could be pretty difficult even with the Audacity and Reaper file lists.

[chrisrimple]

Admittedly, if "start/stop recording" isn't available from the client, then maybe a recording length limit doesn't matter - as a server operator, I'm still going to have to use SIGUSR to start/restart recording so that I can download after a rehearsal. But the original intent of avoiding stupidly long recordings makes sense, so perhaps default to 8 hours for Default Record Length?

[pljones]

"Max. Record Time" sounds to like no recording can be longer than that time.

Which is what it represents exactly.

I think "Default Record Length" is a better title.

Not for its function. It's function is the maximum length of a recording session. A recording session is what ends up in one RPP or LOF (i.e. one sub-directory of the main recording directory).

The recorder remains enabled. Just like with the "start a new recording" button or SIGUSR1. But the recording ends.

"Recording Session" is a bit long-winded. And --maxsession doesn't mention recording. So I went with --maxrecord.

[pljones]

if "start/stop recording" isn't available from the client, then maybe a recording length limit doesn't matter - as a server operator, I'm still going to have to use SIGUSR to start/restart recording so that I can download after a rehearsal.

If I can work out how best to get the server-side chat parsing in, the restart will be available. You'll need to enable it at the server -- but then anyone will be able to request the recording session starts afresh, whenever they like. (There'll be no notice to users that it's enabled.) Possibly in "director" mode, it could only be the director who has the power.

[ann0see]

Chat parsing isn’t difficult:

Just check if the received message e.g. matches a regx /starts with a specific string,... you can look at my code.

"Director Mode" has been implemented in my fork too. But it’s way from secure and probably not wanted in the official jamulus software.

[pljones]

@ann0see
String parsing isn't difficult.

I need to do more than that. I need to have certain server functions performed and I need to provide feedback to the client that made the request, without notifying anyone else.

[chrisrimple]

I don't like "max record time" because it implies an outside max but says nothing about the default length, and implies that the length could be variable. Maybe I'm over-thinking it, since "default record length" has the same problem. :)

@pljones You said "There'll be no notice to users that it's enabled". Does that mean the "[Recording]" message in the Mixer view would no longer be shown? I think that's nice for users, so they realize if they are/are not being recorded.

[ann0see]

need to provide feedback to the client that made the request

There’s a function for that too (which sends the welcome message)

[pljones]

@chrisrimple
There is no "default length", hence nothing is implied about a default length.

"There'll be no notice to users that it's enabled". Does that mean the "[Recording]" message in the Mixer view would no longer be shown

No. That's a different thing. I'm talking about a new function that doesn't currently exist. There's no current information provided to the user about it as it's not there. There will remain no information to the user about it once it is there.

[pljones]

There’s a function for that too (which sends the welcome message)

Yes, the bits are there but it needs existing things taking apart and putting back together carefully.

[corrados]

having some kind of chat text parser, similarly to how the NINJAM server has chat commands

Actually, I don't like this feature. For Ninjam it is required since you have to set the tempo and number of bars. That is essential for Ninjam to work properly. For Jamulus we do not have such a requirement.

[WolfganP]

I don't think a timed recording session is a good idea, as it will potentially be off sync with what the band is doing at the timeout end (ie furiously in the middle of a jam :-) and may cut the recording (either losing some synchronization or forcing later to edit the recordings to get the track reassembled).

I think that for the use case of avoiding lengthy recordings, a manual way to complement the current SIGUSR mechanism via the client remotely (settings button, chat commands, director role required, ...) is preferable (from my perspective).

[pljones]

having some kind of chat text parser, similarly to how the NINJAM server has chat commands

Actually, I don't like this feature. For Ninjam it is required since you have to set the tempo and number of bars. That is essential for Ninjam to work properly. For Jamulus we do not have such a requirement.

Yes, I'm hesitant myself. It's bottom of the list of things I'd do.

@WolfganP -- if you don't like it, simple: don't use it. Not every jam happens when the server operator is sitting in front of the server monitoring things, though. On a well-used server, in fact, maybe most don't.

I've another planned feature I'm wondering about but didn't mention -- "minimum participants to record". The ninbot.com server records only when more than one person is participating in a jam. (It also checks level -- I wouldn't.)

[gilgongo]

Minor documentation question: I take it that time rather than size is a better measure of limitation (so we didn't go for "maxsize" if it was just about disk space use). But is there a general rule of thumb to apply about file size over time? For example, are we talking about 10Mb/min per player or something? Might be useful to know if people are thinking about setting the --maxrecord time but also concerned with storage.

[pljones]

At 48,000 samples per second and 16 bits per sample, we're talking 96,000 bytes per second. That's about 100K per second, so 1 minute is about 6M. That's per player. So if 10 people are on, that's 60M per minute.

[rdelferraro]

I'm not coding man, but heavy user...., when a server run in -R mode, the first one that start a connection to the server will start new recording directory, I suggest to give to this one the privilege to stop/start or renew the directory, with a simple client red button visible only to him. I hope this will resolve some conflict on who may stop/start recording. Jamulus is fantastic tool that helped us to overcame lockdown, thanks to all that contribute to development.

[pljones]

So if A joins, then B joins and A leaves, what? If C joins then A comes back, what? There are too many "doesn't really work" scenarios with that approach.

[rdelferraro]

If A leave, the recording should remain on untill all users leave, like
actual beaviour.
If A came back (with the same ip address of the first session that start
recording) may have the red button again and can still off/on.
If all leave the new first one that connect will have the recording
controll, this is the way to change the master.
Who have the control may be notify in the recording banner.
Best Regards
Roberto.

Il Dom 11 Ott 2020, 10:20 Peter L Jones [e-mail] ha
scritto:

So if A joins, then B joins and A leaves, what? If C joins then A comes
back, what? There are too many "doesn't really work" scenarios with that
approach.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/corrados/jamulus/issues/629#issuecomment-706669002,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARKQ7MICULCCUUMUNME3OQTSKFTFRANCNFSM4R3NPB7A
.

[pljones]

But why should A have control over whether B and C are being recorded when A isn't even there? I mean, A might have been on the server by mistake and B and C had planned to meet - they're forced to disconnect and reconnect to get the recorder to stop. No, it doesn't seem right.

[trombonepizza]

I would prefer the SIGUSR1 and SIGUSR2 kill commands to remain the exclusive province of the server owner. If these changes are implemented I would probably use an older version to retain this.

[pljones]

There would be server options to enable them, off by default. However, the more I've thought about it, the less I've liked my idea :).

[corrados]

I just removed the " _/ chat commands_" from the title.