Improve recording recovery script and add to Jamulus install

[chrisrimple]

In #130, @pljones provides a script to rebuild an RPP file when the server fails to create one for a recorded session. I have a few requests...

• Create a duplicate script to make the LOF file for Audacity
• Add both scripts (or a combined script) to the Jamulus Server install (at least headless, maybe GUI as well)
• Provide basic instructions on editing/operating the script

I think there are many people operating Jamulus cloud servers that would benefit from these additions.

[pljones]

It should be easy enough for the same script to generate the LOF whilst it's doing the RPP - the calculations need to be done, it's just the output format that differs, really.

I've just fixed the help text (yes, it had a --help option already ;) ) to point out the one potential issue -- it must be given the correct server fast update value (and currently it only understands -F not --fastupdate). That could be a command line option.

It also generates the RPP UUIDs using the server name -- currently set as a variable in the script, again would be better as a command line option. (I really want a FQDN for the name to be "officially correct" in creating my named UUIDs... :) )

Then perhaps allow a choice of RPP, LOF or both - default being both.

[pljones]

I've started work on this... (This is just to say "I've started" -- I've not tested that the code does what it currently does, which is what it should and I've not started on the LOF side at all, except to allow a filename to be given.)
https://github.com/pljones/jamulus-jamexporter/blob/feature/recover-lof/src/bash/recover-recording.sh

[pljones]

@chrisrimple, PR #775 (merged) provides the final version, including LOF support. I tweaked a couple of bits from the one above, too.

[pljones]

From the original request, this bit is outstanding:

Add both scripts (or a combined script) to the Jamulus Server install (at least headless, maybe GUI as well)

I'm not sure how this would work. The recovery script has dependencies (bash, various shell tools, sox). It's also in one of the module sub-projects. So the (Linux-only?) build would need to ensure that sub-project was current, then the (per-distribution) build would need the new dependencies added.

@corrados -- Is this something you'd be happy having added to the main distribution?

[chrisrimple]

@pljones My thinking about including it with the install is to provide the unedited .sh file somewhere under the install path, just as is done for the unedited jamulus.service file, then include instructions (in the file?) for what needs to be edited, any permissions that need to be set, where the file should be moved (if necessary for execution), etc.

[pljones]

Whilst the --help option explains how to run it, it probably could do with a page explaining it.

It's a bit vicious. Any empty or non-recoverable file gets rm applied to it with a heavy hand. That's probably the bit to be aware of that isn't made particularly clear anywhere...

It complains if it's clearly run from the wrong place (dirname doesn't start Jam-) -- but if you fool around you can confuse it... it's not that careful (and it uses the dirname to set the Reaper file header date, so it's expected to be correct... for Reaper).

Plus it wants uuidgen, ffprobe, sox and soxi in PATH. Oh, and cat, awk and date, and I'm taking as read it's run under a decent version of bash.

[corrados]

What is the status of this issue?

[pljones]

What is the status of this issue?

#750 (comment)

Inclusion in the main distribution is all I see outstanding from what @chrisrimple was asking for.

[corrados]

Inclusion in the main distribution

@chrisrimple What exactly do I have to do to support this?

[pljones]

Also, it might make sense to think more in terms of having this controlled from
https://github.com/vdellamea/jamulus-server-remote
rather than being part of the Jamulus server code, I think there's a strong argument against it being included.

[MITEL-UNIUD]

This is an extremely useful script in the rare cases you need it. In those cases, you might be willing to do some extra work. I think what Chris is suggesting here : #750 (comment) is more than sufficient. Said that, the server remote can be easily adapted to run it too.

[corrados]

Also, it might make sense to think more in terms of having this controlled from https://github.com/vdellamea/jamulus-server-remote

That's an interesting project. I just added it as a submodule in the tools directory of Jamulus.

[vdellamea]

Thanks. By the way, I just released some minor update (and the previous comment it's me with the work account - sometimes I make some confusion :) .