"Aurdio record" overrides file after restart

[ittixen Bledsoe]

The problem: after a restart for any reason (app/phone crash, OoM, premium verification failure, etc.), the block "resumes" recording, in fact starting a new recording to the same file, thus deleting whatever was already recorded.

Possible suggestions:

• After a restart, before "resuming" a recording block, rename the existing target file (e.g. from "rec123.aac" to "rec123.backup.aac"). I tried to implement this myself but it cannot be done as a user because the recording block will "resume" before the renaming block can run. Even an external tool can't run fast enough in many cases.
• Alternatively, copy the target file to a backup file (same as above but keep the original). This way if the recording actually continues the user can delete backup file, and if it restarts the user doesn't lose the previously recorded audio. One big problem with this option is it could unexpectedly fill up the storage space and crash the device if no precautions are taken.
  
• Avoid "resuming" a recording block entirely and throw an error instead. This will allow the user to decide how to handle such a case (e.g. start a new recording with a new filename). Personally I think this is the best option, giving the user the most control and avoiding unpredicted points of failure. If this is backward-incompatible (e.g. users might rely on the existing behavior and this change could break their flows), it could be enabled via a flag in the "Audio record" block.
  

P.S.

I lost so many hours of audio to this, but I have no options other than Automate for my uses. Recently made a frustrated review on Google Play, but should have come here a long time ago. The fact that Google controls the premium verification process has nothing to do with the way the app itself records to files. Additionally, this brings me to another issue: the way Automate handles premium verification errors. But I will make a separate post about this, to avoid changing the subject at hand: recorded files being rewritten after a restart.

[Henrik "The Developer" Lindqvist]

The app doesn't restart due to a premium verification problem, it will simply prevent starting more flows.

If the Destination path lacks a filename, i.e. its completely empty or point to a directory, then it should generate a unique filename each time.

[ittixen Bledsoe]

I mistakenly attributed the restart to the verification error, because I got this error when the app crashed, probably due to my phone being out of memory. But this doesn't mean everything I said should be ignored. Again, the premium verification is not the issue here. The issue is the restart itself. When the block resumes after a restart, it still uses the same filename it was using before the crash (whatever the reason for the crash was).

[Henrik "The Developer" Lindqvist]

As said, include some unique counter into the destination filename, e.g. recording{Now}.mp3, or point it to a directory or leave empty to generate a unique filename each time.

[ittixen Bledsoe]

I know. I am generating a unique filename (timestamp-based) every single time. But since I have to store this path in a variable (in order to create the directory first), it persists through crash/resume. Again, the problem is not that the variable persists (any other behavior wouldn't make sense). But I have to generate the path before the recording block and store it in a variable, to use in both "File make directory" and "Audio record", if I want to use my naming convention ("yyyy/MM/dd/HHmmss.aac"). Because if I use it directly inside the "Audio record" block, the directory can get a "NoSuchFileException" if the date changes between crash and resume (e.g. I start recording at 23:00, the app crashes at 23:40, and then I start the app at 00:10, so the directory for today doesn't exist).

But I'm tired of this. This isn't a discussion, it's just me trying to explain things only to be misunderstood and dismissed. I just went with a workaround where the directory's date doesn't always match the file's date (using yesterday's directory for today's file).

[Henrik "The Developer" Lindqvist]

There's no need to store it in a variable before the block, include the timestamp-based name in the Destination path input argument, and assign it as the Audio file output variable instead. Also, use an File make directory block for /yyyy/MM/dd prior.

I don't think i misunderstand, i simply trying to tell you how to work around the issue you're having. I'm sorry if you feel dismissed, but i cannot simply remake how the block works on a whim just to suit your particular needs. The block do what its input argument tell it to.