[Bug]: AudioFileManager doesn't handle removed files

[JelleBakker]

Detailed steps on how to reproduce the bug

If a known file in AudioFileManager is removed from disk, it currently is not removed from knownFiles. Instead AudioFileManager::checkFileTime thinks the file was changed and will try to re-parse the file, continuously. This will fail, because the file doesn't exist anymore. We think that AudioFileManager should detect file removal and in that case remove the file from the knownFiles map.

In our application we allow the user to create and destroy tracktion edits quite frequently. We also delete project files including associated audio files if the user wants to overwrite an existing project. If the user creates a file with the same name of a file that was previously deleted, the file is still cached in knownFiles as having a samplerate of 0 (invalid). When we try to load an audio file, we construct a tracktion::AudioFile and call isValid() immediately after to check if we can load the file. Under the hood isValid relies on AudioFileManager::getInfo but since the timer calling checkFileForChanges has not run yet to perform the update, isValid will return false.

To demonstrate the problem, here's some pseudo code:

jassert(tracktion::AudioFile(file).isValid()); // OK
file.deleteFile();
// wait for a few seconds (so the timer calling `checkFilesForChanges` can run)
file.recreateFile();
jassert(tracktion::AudioFile(file).isValid()); // FAILS

We have a few suggestions for improvement:

1. As mentioned above AudioFileManager should detect file removal and in that case remove the file from the knownFiles map.
2. It would be convenient for us if there was a clearKnownFiles() function in AudioFileManager. This would allow us to cleanup the knownFiles in between opening/deleting edits.
3. After we delete the edit, AudioFileManager still exists, but checkFilesForChanges is never called because it's called from a timer that exists within an edit (TransportControl). From a software design perspective it feels strange that the AudioFileManager lives at Engine level, while it relies on edits to function.
4. Another potential solution and a massive simplification would be to perform the file updates within AudioFileManager::getInfo instead of relying on a timer that performs the updates asynchronously. This would solve all problems. (but perhaps the perfomance impact is too big, we don't know).

What is the expected behaviour?

Unit test to reproduce the error?

-

Operating systems

macOS

What versions of the operating systems?

macOS 15.6.1 (24G90)

Architectures

ARM

Stacktrace

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the develop branch

The bug is present on the develop branch

Code of Conduct

• I agree to follow the Code of Conduct

[drowaudio]

The problem is that this is all part of a caching system so forcing update checking during getInfo would add quite a bit of overhead.

We have this problem during recording which is why forceFileUpdate is there.
(You could use checkFileForChanges but this uses the time-stamp which only had millisecond precision which isn't always accurate enough).

Maybe adding a function AudioFile createAudioFileCheckingForChanges (Engine&, const juce::File&) is what you need?