Is it possible that something about the way rclone is grabbing these chunks is causing VLC to crash? For example, shouldn't it breeding at offset 0 (or close to it)?
I have never had a problem playing a video copied to local storage before playing it.
In instances that seem to crash VLC, attempting to play the file with QuickTime player simply locks up QT Player, so I do believe there is an issue with reading/streaming back the file, and simply each player responds differently to the same issue (whatever that may be).
I have tried using smaller chunk sizes, thinking that perhaps that would allow play to start more quickly, and allow quicker response within the video player(s). Am I off base on that? Should I continue to tweak the chunk size, or is that not likely to yield results?
I do not have a tremendous amount of local storage, so I would like to keep the local cache size to roughly 1GB...
Are you using the cache backend? That's the only backend that really uses local storage for reading files. The mount command you have uses 0 local storage above, but without the rclone.conf, it's hard to tell.
When you say chunk sizes, what do you mean? What setting are you changing?
That is just the range http request it sends to Google Drive and is not related to local chunk size. A larger size here is just less API calls per file.
Correct, but my understanding is that once a call is issued, the entire chunk is downloaded.
For example, let's say I've set a 100MB chunk size (just for round numbers). Then start playing a video. 100MB of that file will begin to download.
If I wait 3 seconds, and then seek half-way through the movie, another 100MB chunk will start to download, but the original download will not stop.
If I wait 3 more seconds, and seek again, I will now have 3 chunks downloading in parallel, until and each will download its full 100MB, regardless of whether that chunk contains video that is viewed by me or not.
In that regard, smaller chunk sizes would be beneficial because it would mean fewer concurrent connections if I was skipping around within a video. Yes/No?
WriteFileHandle: Can't open for write without O_TRUNC on existing file without --vfs-cache-mode >= writes
error... which makes no effing sense to me. Adding --read-only to my mount obviously fixes it, and slightly reduces how laggy the Finder gets. But that's not really a permanent solution. Surely I can't be the only one?
It might be that some program is carelessly opening a file for both read and write when it should only be opening it for read. That should be visible in the debug logs.
No, that's not right. Nothing happens in parallel. If you have a read request on a file and you stop reading, it calls a flush, which closes the file and drops the buffer. Anything in flight is gone. It re-opens the file and starts the process again.
You can see that in the debug logs via the Opens and the Flushes.
As I shared earlier, the chunk size it just a range request sent via HTTP for what the read. Nothing is ever downloaded and it's only stored in memory until the file is closed (seen via a flush).
In general, you'd get benefit from a smaller chunk size by wasting less of a download if the file is closed. It's pretty minimal in use though.
It's hard to tell. Those errors start appearing as soon as I browse the mount in Finder. If the file is a video, they recur as it is played.
My current thinking is that it is due to Finder trying to update information in the resource fork. I haven't gotten a chance to try with --noapplexattr to try and investigate that theory yet
