Playing video files over samba mounted rclone mount

Help and Support
1

Hi, I'm using samba to share a rclone mount directory.

rclone mount gcrypt: /GD --allow-other --dir-cache-time 96h --drive-chunk-size 32M --log-level INFO --log-file /opt/rclone/logs/rclone.log --timeout 1h --umask 002

Any idea on how to get decent performance with vlc (or other players if you can recommend one)? Basically SD works fine, FHD chops, 4K is unplayable.

Single transfer copy performance from google drive to my server is 20MB/s. Samba setup from local hdd is fine as well. I tried --buffer-size=100M which only increased seek times in vlc. Nothing in the logs, own API key, rclone 1.47

2

Why not just serve http/webdav instead of samba. Then you can browse with a browser and stream with vlc or other clients. http/webdav will function much better than samba if it fits your use case.

3

In my experience the browsing performance is quite poor for a huge amount of files. Plus I like my search and filtering tools that come with file system level access.

4

dir-cache-time makes it quite snappy. Not sure what you mean about poor performance. I stream and browse without a single issue. Been using it for a long time now.

5

So what do you use for playing and browsing? 5k-50k files per directory, filtering of names and creation time is a must, preferably regex.

6

I use a browser to browse http and then open links in vlc or mx player or whatever player I want. I also have a webdav which I use either kodi or a webdav client for android or linux.
vlc or mx player is good for quick access on android. I use vlc and others from a desktop. Kodi uses webdav as a source as well for my main TV/Media centers. They all stream perfectly.

The one pain point you will have right now is if you use rclone serve http, you won't get times in the default rclone web server templates but that is being worked on hopefully for the next release with better templating.

If you want a light-weight solution using http rather than samba (which always seems to have performance issues in the forums) then the other possibility is to run caddy as a webserver frontend with the rclone mount as a backend. caddy is super easy to implement and the browser interface is pretty nice for filtering and such.

image
image.png1081×359 61.1 KB

I prefer to keep things simple.

7

Is there anything I have to watch out for with caddy config? I still get stuttering with my minimal caddy config, although it is better that using samba:

192.168.10.1:8000
browse
8

Nope. That simple browse should be enough. Just know that it has zero security like that but I know you're just testing... caddy should be fine. Now its a question of why you're getting studdering and most likely from the mount you're pointing to.

My mount I use:
--buffer-size 150M
--dir-cache-time 485h
--vfs-cache-mode writes
--vfs-read-chunk-size 50M
--vfs-read-chunk-size-limit 300M \

Your use case may use different numbers but just mentioning what mine are.

Could also be network related. If you use a local file, do you still get studder? and a debug log file will help to see.

9

I used your settings (besides chrunk size, rclone won't start for me if its not a power of 2)

RCLONE_CONFIG=/opt/rclone/rclone.conf /usr/bin/rclone mount cgdrive: /gdrive --allow-other --dir-cache-time 96h --drive-chunk-size 64M --vfs-read-chunk-size-limit 300M --vfs-cache-mode writes --buffer-size 150M -vv

The log doesn't show anything special when stuttering occours. Playing a file from local storage works fine.

I noticed that transfer speeds when downloading from rclone mount are quite a bit slower than using rclone copy (2MB/s vs 20-30MB/s), so I guess thats the issue.

10

Can you share the actual log file?

11

fyi. This is over a caddy webserver against a mount. same as you.

root@xxxx:/data/bin# curl https://xxxx:xxxx@xxxxxxx:xxxx/some/path/movie.mkv > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1130M 100 1130M 0 0 16.4M 0 0:01:08 0:01:08 --:--:-- 21.5M

You have something else going on....

Same file from the mount itself...
root@xx# dd if=movie.mkv of=/dev/null status=progress
2316229+1 records in
2316229+1 records out
1185909593 bytes (1.2 GB, 1.1 GiB) copied, 24.7994 s, 47.8 MB/s

12

Here is the log until it wasn't watchable for 30s: https://paste.ubuntu.com/p/mDx7FrmRGT/

root@hostname:~# curl http://PATH.mkv > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0 34.4G    0 44.7M    0     0  1102k      0  9:06:13  0:00:41  9:05:32 1516k

Current speed sporadically drops to 0 during transfer.

root@hostname:~# dd if=/PATH.mkv of=/dev/null status=progress
961397248 bytes (961 MB, 917 MiB) copied, 33.4164 s, 28.8 MB/s

So it seems there's something going on with caddy

13

Perhaps resource restriction like CPU or memory? My caddy is running with the overhead of HTTPS and I can get good speeds through it.

100 1130M 100 1130M 0 0 23.7M 0 0:00:47 0:00:47 --:--:-- 33.0M

100 1130M 100 1130M 0 0 38.7M 0 0:00:29 0:00:29 --:--:-- 49.7M

14

When you check your log, does it open and close a lot?

2019/05/23 16:55:48 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:48 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:49 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:49 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:50 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
2019/05/23 16:55:50 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
2019/05/23 16:55:50 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
2019/05/23 16:55:50 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
2019/05/23 16:55:50 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:50 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:50 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:50 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:51 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
2019/05/23 16:55:51 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
2019/05/23 16:55:52 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
2019/05/23 16:55:52 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
2019/05/23 16:55:52 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:52 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:56 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:56 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:56 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
2019/05/23 16:55:56 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
2019/05/23 16:55:58 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:58 DEBUG : movies/UHDTEST.mkv: Open: flags=O_RDONLY
2019/05/23 16:55:58 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
2019/05/23 16:55:58 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
2019/05/23 16:58:06 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
2019/05/23 16:58:06 DEBUG : &{movies/UHDTEST.mkv (r)}: >Flush: err=<nil>
15

Once it gets going, it doesn't. He posted the log up top.

16

CPU and Memory usage are next to zero.

I only played one file and didn't close until the end. I skipped a bit once, mb its that with the flushes?

17 
2019/05/23 16:56:01 DEBUG : movies/UHDTEST.mkv: ChunkedReader.Read at 7818612736 length 1048576 chunkOffset 7686496256 chunkSize 134217728
2019/05/23 16:56:01 DEBUG : movies/UHDTEST.mkv: ChunkedReader.Read at 7819661312 length 1048576 chunkOffset 7686496256 chunkSize 134217728
2019/05/23 16:56:01 DEBUG : movies/UHDTEST.mkv: ChunkedReader.Read at 7820709888 length 1048576 chunkOffset 7686496256 chunkSize 134217728
2019/05/23 16:56:01 DEBUG : movies/UHDTEST.mkv: ChunkedReader.Read at 7820713984 length 1044480 chunkOffset 7686496256 chunkSize 134217728
2019/05/23 16:56:01 DEBUG : movies/UHDTEST.mkv: ChunkedReader.openRange at 7820713984 length 268435456
2019/05/23 16:56:01 DEBUG : movies/UHDTEST.mkv: ChunkedReader.Read at 7821758464 length 1048576 chunkOffset 7820713984 chunkSize 268435456
2019/05/23 16:56:01 DEBUG : &{movies/UHDTEST.mkv (r)}: Read: len=131072, offset=7736827904
2019/05/23 16:56:01 DEBUG : &{movies/UHDTEST.mkv (r)}: >Read: read=131072, err=<nil>
..
..
..
2019/05/23 16:58:06 DEBUG : &{movies/UHDTEST.mkv (r)}: Release:
2019/05/23 16:58:06 DEBUG : movies/UHDTEST.mkv: ReadFileHandle.Release closing
2019/05/23 16:58:06 DEBUG : &{movies/UHDTEST.mkv (r)}: Flush:

You can see it chunking just fine between those. It doesn't open and close the file...

Let's just take caddy out of the picture to test. Lets do this:

rclone serve http /the/mount/point

use the same parameters as the mount really. You won't get the pretty caddy file browser but at least we can test throughput of http and narrow down perhaps.

18

Okay rclone serve looks about the same as with caddy

root@hostname:~# curl http://127.0.0.1:8080/PATH.mkv > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0 34.4G    0  192M    0     0  2819k      0  3:33:34  0:01:10  3:32:24 1318k

It drops to 0 as well during download

19

So it isn't caddy either. Not sure. Something is slowing you down...

You could try to serve it directly (taking the interaction with the mount out of the equation).

rclone serve http cgdrive: --dir-cache-time 96h --drive-chunk-size 64M --vfs-read-chunk-size-limit 300M --vfs-cache-mode writes --buffer-size 150M -vv

Its interesting though. Sure seems like both samba and http are seeing the same symptom.

20

Sorry for the confusion, the latest curl was exactly that. Same as with caddy