MountainDuck cache seems to cache very little even when working with large reads

[rwaldspur]

When doing reads on larger media files (e.g. playing video files direclty in VLC), or scanning media on Plex, the cache directories contain very little storage. For example, when reading several TB of data, the cache remains less than 10 GB, despite it being set to a limit of 200 GB.

Additionally, I don't see any of the files show up as "Sync" in the title bar MountainDuck History list. I see a lot of network activity associated with MountainDuck during these reads, but no display of what file is being read, and seemingly no deposit in the cache.

I'm not doing uploads generally, but rather downloads.
I've done fresh installs on a couple of machines, with similar results.

HOWEVER... when I choose to "Keep Offline on Local Disk", it stores the files in cache as expected.

Perhaps for these media files Mountain Duck is doing partial file reads, and this doesn't trigger storage in cache?

Should this be the correct behavior?
-- is there anyway to get MountainDuck to utilize the cache during these reads?
-- is there any way to get MountainDuck to show the file that is being read?

Backends:
Google Drive or DropBox

Mountain Duck version 4.15.3 (21820)

With or without Cryptomator vaults connected with MountainDuck

Settings:
Smart Syncrhonization -- with or without Buffering
Cache Setting large enough (200 GB) that I might expect some "build-up."

macOS 13.16.4 (Ventura)
macOS 10.15.7 (Catalina)

[tatze96]

If you stream a file, for example, a video file, from the server to the used application, the file won't be queued for synchronization. Streamed items also only get moved into the synchronization cache if downloaded completely and closed by the reading application, which likely causes the described small cache size. The partially buffered content is generally placed within the operating system's temporary cache location and gets removed if the file doesn't get read through completely.

Some applications can only open files knowing their complete length and content, and they will cause the file to be completely downloaded into the cache before opening it.

[rwaldspur]

Thanks so much for this useful info.

In my case, are there any set of preferences that might cause the following behavior(s):

1. Save the bits of the file that were in the temporary cache (that have been already read), and promote these bits to the cache folder?
   or
2. Cause the reading of a portion of the file to trigger a background read of the rest of the file into the cache folder, and (ideally) not cause the application to wait for the entire file to be loaded before it can work with the data?

In my case, I'm doing file maintenance, and the applications at times are reading in huge portions of the files. When I try another operation on a file I recently had touched, but has since been closed, it begins downloading most of the file all over again.

If the behavior I'm looking for is not possible, I'm guessing the next best option would be to dedicate a large permanent cache space, and just keep the folders of interest always available offline.

As for the notification that a file is being read -- that would be a great feature for the user to know which file is being interacted with. When there are a lot of file oprations, it's not always easy to tell which file is being read at a given moment.

Again, many thanks.

[tatze96]

Regarding the first point:
Streamed bytes are written into the buffer (temporary system cache) and will be moved into the synchronization cache once the file is closed and the buffer is complete. Otherwise, the buffered parts will be discarded without being moved into the synchronization cache. We don't have any settings or preferences available that would allow for partial caching.

Partial caching will be supported by the new connection mode in Mountain Duck 5. We can't provide a specific release date for major version 5 yet.

Regarding the second point:
Mountain Duck doesn't block applications from interacting with the file's contents while reading it. The application gets the requested bytes delivered in a continuous stream.