Rclone crashes VLC

Has anyone else experienced an issue where opening a video file from an rclone crypt remote crashes VLC on startup?

FUSE for MacOS Pref Pane (v.3.10.3)
Fully default mount parameters i.e.

$ rclone mount remote: /localdrive

debug output:
2019/11/12 15:41:03 DEBUG : &{test1080p.mp4 (r)}: >Read: read=32768, err=
2019/11/12 15:41:03 DEBUG : &{test1080p.mp4 (r)}: Read: len=32768, offset=74862592
2019/11/12 15:41:03 DEBUG : &{test1080p.mp4 (r)}: >Read: read=32768, err=
2019/11/12 15:41:03 DEBUG : &{test1080p.mp4 (r)}: Read: len=36864, offset=74895360
2019/11/12 15:41:03 DEBUG : &{test1080p.mp4 (r)}: >Read: read=36864, err=
2019/11/12 15:41:03 DEBUG : &{test1080p.mp4 (r)}: Flush:
2019/11/12 15:41:03 DEBUG : &{test1080p.mp4 (r)}: >Flush: err=
2019/11/12 15:41:03 DEBUG : &{test1080p.mp4 (r)}: Release:
2019/11/12 15:41:03 DEBUG : test1080p.mp4: ReadFileHandle.Release closing
2019/11/12 15:41:04 DEBUG : test1080p.mp4: ChunkedReader.Read at 76546048 length 1048576 chunkOffset 4096 chunkSize 134217728
2019/11/12 15:41:04 DEBUG : &{test1080p.mp4 (r)}: >Release: err=

If you copy the file to local storage then try VLC does it still crash it?

There don't appear to be any errors in your log.


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)?

On a Mac and can't reproduce your error on a mount as VLC plays everything fine for me.



and VLC


If rclone is reading the file wrong then it is corrupting data. I really hope it isn't doing that!

If you copy the file from the mount and compare it to the original (maybe with rclone md5sum) is it identical?

This is probably a bug in VLC I'd say!

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?

Do you any malware scanners or virus scanners?

I am not using the cache backend.

I mean vfs-read-chunk-size

No malware/virus scanners.

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.

@dr.mcgillicuddy can you try this please? It will tell us whether rclone is corrupting the file or not.

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?

rclone md5sum ~/Desktop/The_Big_Lebowski.mp4
e4209d9990c5bbee712f005c2ab7e6b6 The_Big_Lebowski.mp4

$ rclone md5sum gdrive:The_Big_Lebowski.mp4
e4209d9990c5bbee712f005c2ab7e6b6 The_Big_Lebowski.mp4

I'm beginning to agree that this is a bug in VLC.

Although I'm still getting the

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?

What program causes that error?

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

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.