I see that, yes. I tried full mode, creating a 2G memory tmpfs because I don't want to store cache files in secondary storage due to high IOwait and stuff.
Rclone drops the cache when a file is closed as that's what is happening as shown in the debug log.
Not sure I understand why a secondary disk would cause problems streaming as streams are much slower than disk IO in general. If that was the case, people would local storage wouldn't ever be able to stream.
Depends on what you are doing and how many concurrent streams / bitrates of those streams / the type of secondary disk / etc.
Full mode solves the problem pretty much and I doubt they really don't fix bigger things let alone something very low level like this as with local storage, it isn't a problem.
OK
So why not use --vfs-cache-mode=full with some small max cache size and short cache time? This will cache just the last movie(s) as sparse files for a short period of time just to compensate for stupid tv applications.
I think that
VFS cache is versatile enough to compensate in a wide range of situations
Too complex in development/testing to add new unwarranted features
Or just use a device that is better suited for the job.
The problem with cheap solutions is that they are cheap.
Similar to use a built in Plex App.
The time invested in trying to work around a bad device / under powered solution would be better spent using a better solution.
Raspberry PIs also have USB ports so you can plug in a flash drive for cache storage if you really wanted to, but if you have slow WiFi, delivering a consistent streaming experience would be tough anyway.
the pizero is fantastic, runs rclone mount, a media server, streams well, runs vpn server.
i use a small usb 5g wifi with it.
and since it supports wired network over usb otp, i use it as a travel router and hotspot.
and yes, i have a pi4 connected with a usb ssd drive.
some rcloners, including myself, do not use --vfs-cache-mode on any device and having a better implemented buffer would be helpful.
i guess time will tell, if there is enough interest in that github issue.
It can't transcode.
I wouldn't ever have my media server on Wifi.
It really depends on the use case.
For a cheap roaming device like you describe, it be great.
For a dedicated media server, it's just a bad solution if the goal is a reliable device. Few more dollars gets a real solution that just works all the time.
It's a not really a buffer issue per se as it is a poorly implement client opening/closing the files rather than streaming them.
There's really no debating on what's better as it's a personal choice. I value stability and lack of touch over being the cheapest so it doesn't work for me.