Firstly, thank you to the awesome folks who have developed this software. As a volunteer reader for librivox (librivox.org), I rely on it for editing voice.
My setup is a small recording booth running linux (kubuntu). Projects are saved to an NFS4-mounted drive on a Truenas server.
Projects are edited on a separate machine running Kubuntu 24.10, which mounts the same nfs network share (again NFS4).
Audacity is from flatpak, and is version 3.7. Appimage from Audacity site behaves the same.
On a 5-minute recording, selecting a 1-s region and hitting delete takes 10s to act. As I have many, many, edits to make this is unworkable.
I haven’t done recording for a couple of months, but the problem was not evident then. I would have been using the latest flatpak version then.
However, if the share is mounted as a SMB (CIFS) drive on the Kubuntu editing machine, the above problem goes away. Editing response times are OK.
A new small niggle is present on the SMB share - the .aup3-wal and/or the .aup3-shm files are left in the project directory after the project is closed and Audacity exited. I can live with this.
Does anybody know of a workaround to make NFS work once more?
True. But that doesn’t naturally fit my workflow. Yes, I can copy the project to a local disk, make my edits, and then copy back to the network - and do this whenever I needed to make an edit. And if the documentation said: “only works well enough from a local disk”, I would have no complaint.
But as it was working well enough previously, but is not now, there is surely some hope that whatever changed can be located and unchanged.
A new small niggle is present on the SMB share - the .aup3-wal and/or the .aup3-shm files are left in the project directory after the project is closed and Audacity exited. I can live with this.
This is pretty bad; those may corrupt your project down the road. Essentially these are edit instructions for the AUP3 database, and applying the same instruction twice can become pretty terrible.
You may want to try using Audacity 2.x instead – that version can handle local temporary files with remote source files, That ability got removed with 3.0 (before my time).
And if the documentation said: “only works well enough from a local disk”, I would have no complaint.
Fwiw: we do say the following on the various /download pages:
Note: Audacity requires fast, uninterrupted access to a hard drive or SSD to operate. Network storage, consumer-grade external hard drives or USB thumbdrives may be unreliable.
Thank you for your response, LWinterberg.
I don’t think I want to move to Audacity 2.x, as I have a bunch of data in 3+ format. Also, I note that Audacity 3.6 won’t open an Audacity 3.7 file and the same lack of backwards compatibility might be true in future, so it is best to keep both machines up to date with the latest version.
I did read the manual, but obviously not closely enough. You’ve got me there with the quote on drive speed.
I think my workaround is going to have to be to mirror my network share using something like nextcloud and work off a local copy. It’s a step back, but needs must.