Has anyone tweaked their cache settings to the point that they can get smooth seeking in videos?
Any recommendations? Any time I try seeking outside of the first chunk, the video refuses to load.
I don't know what you define as "smooth" here, but...
I think the most you can reasonably expect while streaming from cloud is 1-2 seconds delay when you seek. That is very usable though.
With the right setup there should not be any issue with seeking aside from it being a bit slower than from local storage though. Sounds like you have more serious problems.
If you want us to help you with this sort of problem you are going to have to provide us with basically your whole setup. Start by posting your mount command + contents of rclone.conf
!warning! - rclone.conf can contain certain sensitive information. Be sure to redact things like client-ID, client-secret, token and any crypt keys before posting. !warning!
You also need to provide us with an exact description of how you play your video. Is it via a mount directly on an OS? If so what mediaplayer do you use? Do you run media through Plex? ect. ect.
Mac OS:
rclone mount googledrive: ~/localmount
I open files off the FUSE mount with either VLC or QuickTime player.
rclone.conf is only:
[googledrive]
type = drive
client_id = stuff
client_secret = morestuff
scope = drive
token = allmysecrets
If I want to set flags to always run with my mount command, can I put them in rclone.conf along with scope, token, etc? For example, could I just add a line after "token" that says ''vfs-cache-mode write" instead of having to pass that every single time via the command line? (I really wish the .conf was better documented...)
Ah, so you are using a very simple and standard setup so far.
That is actually very good in terms of troubleshooting 
I'm afraid this is not currently possible 
The current supports for flags in the config file is:
- Backend spesific flags: YES
Backend-spesific flags are any flags that only apply to a certain backend (like settings for Gdrive, cache-backend, Crypt ect.) - General flags: NO
General flags are flags that apply to rclone in general (for example --transfers. vfs-cache-mode writes, --checksum ect.)
NCW (the main author) is aware of this limitation and intends to fix it eventually - but it is going to take some major code-restructuring, so it is a lot of work.
The best solution meanwhile is to make some scripts for the tasks you often perform so you don't have to remember all the flags every time, or at least have a textfile you can copy-paste the flag-sets you use the most from easily
Ok, so wit that out of the way - lets continue figuring out your problem...
This confuses me a little bit, because it sounds like you are using the cache-backend - but I can not see any cache-backend being used in your config. (it is usually not required to get good media-playback just to clear). Do you think this may be a misunderstanding on your part? I just want to make sure I am not missing anything.
Clarify some details for me please:
- While using VLC, do your videos start reasonably quick? (a few seconds to start may be normal)
- While using VLC, do the videos play without stuttering if you do not seek?
- While using VLC, when you try to seek in the video - does it buffer forever or is it just very slow? Do you get any errors or other unusual behavior from VLC?
Lastly, if you want to be extra thorough and give me the best possible chance of finding the problem, you can make a DEBUG log for me.
You would do that by adding the following flags:
--log-level DEBUG
--log-file="MyDebugLog.txt"
then, go make the problem happen. When you think you have demonstrated the problem - close the mount and remove the flags. Post the debug log here or PM it to me if you prefer. It should not contain much sensitive information - but it can potentially show the names of some of the files and folders.
If the log is very large you may need to post it to pastebin and give a link instead. Debug logs grow very very large quickly...
I will make recommendation about any setting changes later once I have a better idea of what exactly is the root of the problem you are seeing
My understanding was that the cache-backend was on by default. The debug output shows chunked reads, so I assumed this was the case. Output is below.
Prior to generating this debug, I checked fast.com and got a sustained 105mbps. The video I'm testing with is an H.246 encoded, 2.5GB file with a data rate of 2.72Mbit/s.
-
While using VLC, do your videos start reasonably quick?
Yes -
While using VLC, do the videos play without stuttering if you do not seek?
Usually--however it's helpful if I press pause for a few seconds immediately after the video loads, and then resume. -
It appears to buffer forever. Occasionally, it resumes if I only seek ahead one time, or it will resume audio but not video. However, let's say I jump to 5 minutes in, let it play for a couple seconds, then I jump another 5 minutes ahead--it buffers forever. The debug output (PMed) occurred in an instance where I jumped from zero minutes to 30 minutes, and the video buffered "forever"
Anyone else reading, I believe this is the crux of the matter:
2019/11/01 12:03:43 DEBUG : &{The_Big_Lebowski.mp4 (w)}: Flush:
2019/11/01 12:03:43 DEBUG : The_Big_Lebowski.mp4: WriteFileHandle.Flush unwritten handle, writing 0 bytes to avoid race conditions
2019/11/01 12:03:43 ERROR : The_Big_Lebowski.mp4: WriteFileHandle: Can't open for write without O_TRUNC on existing file without --vfs-cache-mode >= writes
2019/11/01 12:03:43 DEBUG : &{The_Big_Lebowski.mp4 (w)}: >Flush: err=operation not permitted
2019/11/01 12:03:43 DEBUG : &{The_Big_Lebowski.mp4 (w)}: Release:
2019/11/01 12:03:43 DEBUG : The_Big_Lebowski.mp4: WriteFileHandle.Release closing
2019/11/01 12:03:43 DEBUG : &{The_Big_Lebowski.mp4 (w)}: >Release: err=
2019/11/01 12:03:45 DEBUG : : Statfs:
2019/11/01 12:03:45 DEBUG : : >Statfs: stat={Blocks:4294967295 Bfree:4294967295 Bavail:4294967295 Files:1000000000 Ffree:1000000000 Bsize:4096 Namelen:255 Frsize:4096}, err=
No, that is incorrect. But I absolutely understand this can be confusing
The VFS-layer (which also has a cache just to make it extra confusing) also uses chunks for both downloading and (usually) for uploading. You are likely seeing the read-chunking of default 128M size.
The cache-backend is an optional module (a remote technically). It's main purpose is to provide a persistent read-cache - as the VFS cache currently only has write-caching.
Your log is showing something is attempting to write... this should not normally be happening when you just stream a video. Video players generally just open the files in pure read-mode. was this from VLC?
Your error is specifically a complaint from rclone that it can't do that sort of write operation without --vfs-cache-mode writes
Of course this is usually NOT required to stream video, because video streaming rarely (never?) require files to be written to - only read. I suppose you could add this and see what happens - it shouldn't hurt - but I'm not sure what would cause this to happen. I will look if I can find anything else in the full log...
I do note one other potential problem:
The_Big_Lebowski.mp4: ChunkedReader.Read at -1 length 4096 chunkOffset 0 chunkSize 134217728
These read-chunks appear to be very very small. This is unusual. By default rclone should be requesting 128M at a time (and doubling for each sequential read until you do a seek at which time it starts again from 128M). This is clearly much much smaller. I would not be surprised at all if this ruined performance and caused many issues.
Are you using this flag anywhere and have forgotten to tell me?
--vfs-read-chunk-size 128M
Because it kind of looks like it is used and has a very low value (maybe for example forgetting to use M so it defaults to kilobytes ?)
To my knowledge, I have not specified any chunk size; whatever rclone is using is part of its default config. Other than passing it along with rclone mount (which I didn't do) is there anywhere else rclone would look for --vfs-read-chunk-size 128M?
Since rclone doesn't use rclone.conf in the way I would expect, I'm not really sure how any backend configuration is done outside of what's passed at run time, or where default flags are even set.
This was run from VLC; I see the same errors with QuickTime Player.
I should add that I can both modify and upload files on this mount, so, I'm a bit confused as to why --vfs-cache-mode writes would be required for some writes but not others...
Also, my understanding is that ERROR : The_Big_Lebowski.mp4: WriteFileHandle: Can't open for write without O_TRUNC on existing file without --vfs-cache-mode >= writes
O_TRUNC, I believe, just indicates a call to open a file with the ability to write; not necessarily a write operation. So this error would simply mean "rclone can't open this file/chunk in a writeable way" with the implication that it is then opening it as read-only. Which should be fine, and not really have an impact on performance. If my understanding is correct.
It's complicated. Straight sequential uploads don't need cache. Stuff like opening files in READ+WRITE mode, truncating and many other things that an OS expects a HDD to be able to do are not possible directly to cloud and thus have to be done locally on the cache before upload.
Short answer: no-cache should be ok for straight uploads, but if you intend to let applications use the Gdrive for storage and workspace then many of them may require writes mode to work (writes mode will emulate all the functions a HDD can do)
You can find the technical details of the limitations of each mode here:
https://rclone.org/commands/rclone_mount/#vfs-cache-mode-off
Strange. Perhaps I am just reading the log wrong then, or it is the application that is just requesting so little data. I am not certain. Unfortunately I still have much to learn in deciphering the DEBUG logs. Maybe @NCW or @Animosity022 can give us a second opinion... (this mention will notify them about this thread)
EDIT: Re-reading it I see the chunk-size is actually correct (134217728bytes / 1024 / 1024 = 128MB). It is the length that is just super low, a mere 4kb. That may indeed indicate it is the player that is requesting such a tiny chunk as the first thing it reads (and it seemed in the log to double in each subsequent read, but that is still going to take a while to spin up to a reasonable speed).
But no, --vfs-read-chunk-size can not be in any config or any other place you might just have missed it. It is one of those global flags that can only be applied either directly in the command - or indirectly in a script if you use a script to mount (as most do). Either way it should be easy to check for it. 128M is the default if not otherwise specified. (I think this point is irrelevant now that I have seen the chunk-size was actually correct).
All backend flags also have a config-string you can use to set in the config instead. It has slightly different format. For example the the command-flag
--drive-server-side-across-configs true would in the config (under your Gdrive section) be
server_side_across_configs = true
You can find the corresponding config strings in the documentation for all backend flags (but you may notice they follow a common pattern).
If you are ever confused about what is and isn't a backend flag, you can reference this:
https://rclone.org/flags/
with time and more experience it will be probably just become intuitive what a "backend" is though
It's used in write-calls yes, but truncating means changing the size. From what I've recently learned, I think the worst consequence of this is just that you might retain some useless padding at the end of the file (and thus unfortunately also changing the hashsum for it). I assume this has to do with block-sizes and such compared to the "real" size of the file. I am still trying to figure out some of the finer details of this myself
My main concern is why the player is requesting write-accrss to begin with. I don't believe this is normal.
See the link I posted above on the tech specs for each cache mode if you want to learn more (you seem bright and eager to learn which is great). The documentation has a ton of solid info.
Normally the kernel caps it at 128Kb. What OS are you running @dr.mcgillicuddy ?
You should see something like this:
2019/11/02 07:21:04 DEBUG : &{TV/Grey's Anatomy/Grey's Anatomy - S16E06.mkv (r)}: >Read: read=131072, err=<nil>
2019/11/02 07:21:04 DEBUG : &{TV/Grey's Anatomy/Grey's Anatomy - S16E06.mkv (r)}: Read: len=131072, offset=511967232
2019/11/02 07:21:04 DEBUG : &{TV/Grey's Anatomy/Grey's Anatomy - S16E06.mkv (r)}: >Read: read=131072, err=<nil>
2019/11/02 07:21:04 DEBUG : &{TV/Grey's Anatomy/Grey's Anatomy - S16E06.mkv (r)}: Read: len=131072, offset=512098304
So is this related to ..?
--max-read-ahead SizeSuffix
Sounds like it.
But that is 128kb by default, so setting that flag should not have any impact here.
@Animosity022
MacOS
I believe some of the smaller chunks are MacOS attempting generate thumbnails after the volume is mounted... But other than that I'm still at a loss.
I increased VLC's buffer to 1.5 seconds and that smoothed things out a bit. However QuickTime Player doesn't have a way to adjust the buffer, so it still does not seek properly.
In fact, trying to play a 1080p video in QuickTime Player will, I kid you not, take down the entire system.
First it pinwheels, the only option is to force quit QT Player. The pinwheel remains. Killing rclone mount does nothing. Attempting to eject the drive in Finder does nothing. Force-relaunching the Finder causes Finder to exit but not reload. The system is then unusable until reboot.
Literally the only non-privileged app/non-kext I've ever seen able render MacOS unusable.
You need to run all those items off. Making thumbnails and such is going to bring things to a crawl. It really isn't rclone, but fuse on mac. I use Plex and not VLC or QT player.
@Animosity022 This is not really an answer/resolution.
"Bring things to a crawl" is very different than "takes down the entire system."
And, thumbnail creation should have nothing to do with the fact that QT Player is unable to reliably play a video from the mount.
Put the mount in debug log, recreate the issue and post the full debug log.
--log-level DEBUG --log-file /somewhere/rclone.log
You'd have to share a log and we can see what's it's doing.
Not every player is designed for playing cloud storage.
I am a mac user as well.
I tested with VLC and had no issues. Seeking was pretty zippy as well as it took maybe 1-2 seconds to pick up playing as I was jumping around a 8GB MKV file.
I tried to test QT player but majority of my stuff is MKV which is not supported.
I didn't see my system come to a crawl, slow down or take down the entire system. It actually worked much better than I would have guessed.
My mount is:
cat mount
rclone mount gcrypt: /Users/textere/GD \
--allow-other \
--buffer-size 256M \
--dir-cache-time 1000h \
--log-level INFO \
--log-file /Users/textere/Downloads/rclone.log \
--poll-interval 15s \
--timeout 1h \
--umask 002 \
--daemon
Hmm. Using your mount doesn't improve my situation any, either.
I'm showing a solid 5MB/sec network usage after trying to seek, but QT Player never resumes playing after a seek.
Dropping the log in a paste:
https://pastebin.com/xkg2fmsu
There are a few odd things.
It's trying to write the file:
2019/11/06 00:10:25 ERROR : The_Big_Lebowski.mp4: WriteFileHandle: Can't open for write without O_TRUNC on existing file without --vfs-cache-mode >= writes
2019/11/06 00:10:35 ERROR : The_Big_Lebowski.mp4: WriteFileHandle: Can't open for write without O_TRUNC on existing file without --vfs-cache-mode >= writes
2019/11/06 00:10:59 ERROR : The_Big_Lebowski.mp4: WriteFileHandle: Can't open for write without O_TRUNC on existing file without --vfs-cache-mode >= writes
2019/11/06 00:11:31 ERROR : The_Big_Lebowski.mp4: WriteFileHandle: Can't open for write without O_TRUNC on existing file without --vfs-cache-mode >= writes
2019/11/06 00:11:50 ERROR : The_Big_Lebowski.mp4: WriteFileHandle: Can't open for write without O_TRUNC on existing file without --vfs-cache-mode >= writes
2019/11/06 00:12:19 ERROR : The_Big_Lebowski.mp4: WriteFileHandle: Can't open for write without O_TRUNC on existing file without --vfs-cache-mode >= writes
Along with a few of these:
2019/11/06 00:10:25 DEBUG : The_Big_Lebowski.mp4: WriteFileHandle.Flush unwritten handle, writing 0 bytes to avoid race conditions
2019/11/06 00:10:35 DEBUG : The_Big_Lebowski.mp4: WriteFileHandle.Flush unwritten handle, writing 0 bytes to avoid race conditions
2019/11/06 00:10:59 DEBUG : The_Big_Lebowski.mp4: WriteFileHandle.Flush unwritten handle, writing 0 bytes to avoid race conditions
2019/11/06 00:11:31 DEBUG : The_Big_Lebowski.mp4: WriteFileHandle.Flush unwritten handle, writing 0 bytes to avoid race conditions
2019/11/06 00:11:50 DEBUG : The_Big_Lebowski.mp4: WriteFileHandle.Flush unwritten handle, writing 0 bytes to avoid race conditions
2019/11/06 00:12:19 DEBUG : The_Big_Lebowski.mp4: WriteFileHandle.Flush unwritten handle, writing 0 bytes to avoid race conditions
Is something else trying to modify the file?
2019/11/06 00:12:19 DEBUG : The_Big_Lebowski.mp4: Open: flags=OpenReadWrite
2019/11/06 00:12:19 DEBUG : The_Big_Lebowski.mp4: Open: flags=O_RDWR
That seems to be the cause as it repeatedly tries to write to the file, which seems to hang things up.
No--and I don't think this is causing it to hang.
When I mount it with vfs write, the debug errors stop, but the performance is the same.