Jamulus: Intermediate Reaper RPP file while recording

[newlaurent62]

I've just made a 3 hour recording with Jamulus server. It seems that everything went fine.

However i notice that there is only one RPP file built when the server stopped.

Could it be possible to put some intermediate RPP files in case of one of them comes to be corrupted.

And acitvate this behaviour with a command line option specifying the number of minutes elasped before another backup ? "--recording-backup 20mn" for example ?

[pljones]

This will need to wait until after #130 -- until there's a way to say "time to tidy up", this can't be done either.

In addition to the timer option (command line and GUI configuration), I'd also suggest a "cut an RPP now" option. From the GUI that's no issue (once #130 is done) -- have to look into how it can be done from the (particularly Windows) command line.

[pljones]

130 is ready for alpha testing. The server should now close down cleanly cutting an RPP file (unless it really crashes out -- I've a script for recovery that I posted somewhere here in that situation).

For #130, I basically booted everyone off the server and shut it down -- the recorder notices and ends what it was doing. For this request, it's a bit more complicated. I'll want to preserve the current details about who is connected and just start a new recording session. I was thinking it might be really simple but it isn't going to be. Probably won't get it done this weekend.

[pljones]

OK, so I'm getting a bit carried away updating the server...
EDIT I've decided I was _definitely_ going too far. Moved to #120 and re-opened there.

I'm also planning to allow headless to take the ~/.config/Jamulus/Jamulusserver.ini file and reload it on SIGUSR1 and write current settings on SIGUSR2. That should cut server downtime when changing settings in headless mode.

_Ideally_, I'd like to get "headless take-over" by a GUI-enabled server but that's probably a separate feature as this is already rather more than I originally planned (and @corrados is probably wondering if I've gone totally mad as it is...).

[pljones]

Reminder to self - things to add to "My server info"

• "local server name" (sent to central server, used by clients in same LAN as server)
• "local port" (changing it probably means restarting the server and likely triggering a re-registration... Also sent to central server and used by clients in same LAN as server)

[pljones]

Note to self:

• SIGHUP - "disconnect" active jam, cutting an RPP (if you want to send HUP every 20 minutes...)

Everything else here moves elsewhere...

[pljones]

OK, latest update is I've _pushed some code_ (which needed a bit of care, as it already had my dive off the deep end included before I trimmed the branch...).
feature/170-allow-triggered-recording-cuts is in my fork. Currently does nothing useful...

Plan:

1. Jam Recorder to have a "cut now" method -- DONE (re-done)
2. Server to expose the Jam Recorder's state (enabled or not, not whether it's running - that's the same as whether the server is "Started", which is exposed already). -- DONE
3. Expose a server method to cut a jam session, which calls the jam recorder method.
4. Catch SIGHUP unix signal and turn it into a new Qt signal
5. Have the server route that new Qt signal to a slot that cuts a new jam session
6. Add a Server GUI widget to show the jam recorder state (not allow setting under this issue)
7. Add a Server GUI widget to cut a jam session button (enabled when server is running and recording enabled)
8. Update Server GUI state widget from server (at start up, just once is enough for now)
9. Route Server GUI Qt signal from new button to slot that tells server to cut a new session

I think that's it... Oh, and that lot probably wants some documentation updates and then someone will need to do the translations on the new widgets.

[pljones]

Bleargh, plans, eh.

Well, @newlaurent62 your wish from #130 should be there - SIGUSR1 should cut a recording and start a new one. It's only on the branch in my fork, though.

Next up is the GUI. Part of me is trying to say "Stop, do that as a separate change. This is done."

[newlaurent62]

@pljones

Let say that we have t0, t1, t2 chronological events:

• t0 : server started, one user connected => start recording
• t1 : SIGUSR1 is sent to the server and generates p1 Reaper project
• t2 : everyone is disconnected, the server has stopped and generates final p2 Reaper project

So my question:

does p1 contain t0 to t1 events and p2 contains t0 to t2 events or
p1 contain t0 to t1 events and p2 contains t1 to t2 events ?

It's only on the branch in my fork, though.

So it cannot be tested ?

[pljones]

p1 contain t0 to t1 events and p2 contains t1 to t2 events ?

This.

It's only on the branch in my fork, though.

So it cannot be tested ?

In the same way you clone corrados/jamulus, you clone my fork pljones/jamulus then checkout the branch, feature/170-allow-triggered-recording-cuts, and build.

EDIT Actually, there's a more "git-ish" way to do it. Clone corrados/jamulus as usual. Then use git remote add -f pljones https://github.com/pljones/jamulus.git and then you can git checkout feature/170-allow-triggered-recording-cuts. I've not done it myself so you may have to check the syntax....

[corrados]

@pljones This is what I just merged, right? If yes, please close this Issue.

[pljones]

Yes it is, I can't close it.