Google Drive not returning corrupted data

I have recently been experiencing media glitching, or no playback at all with Jellyfin. I have troubleshooted the Jellyfin side and does not appear to be the root cause. I have already read through the few posts related to this subject.

The datasource for Jellyfin is a crypted rclone remote mounted on a directory read-only. To the best of my knowledge the problem started happening roughly around the time the server ran out of disk space. I have no idea how a lack of disk space affected a read-only mounted crypted remote, doesn't make sense.
I have verified md5 and sha256 sums against of few of the files in question which are returning identical hashes (below).

For the moment I have mounted another crypted remote read-only which contains identical data from the primary account, which at the moment appears to be working smoothly.

I would like to know if anyone else has had this or similar problem or if there is anything else I can do in order to troubleshoot deeper. I don't think simply comparing hashes is going to solve this or get closer to root cause.

(local data on zfs) <> (rclone sync) >> (crypted gdrive 1) >> (crypted gdrive 2) >> (crypted gdrive 3)

MD5: 19cfb3d261494862db4d77a07477a6b6
SHA256: 9bf53c7212a6cc81d1d1d0efaf1be714076ad220b56c52fb5b9b9367b7c27560

MD5: 19cfb3d261494862db4d77a07477a6b6
SHA256: 9bf53c7212a6cc81d1d1d0efaf1be714076ad220b56c52fb5b9b9367b7c27560

MD5: 19cfb3d261494862db4d77a07477a6b6
SHA256: 9bf53c7212a6cc81d1d1d0efaf1be714076ad220b56c52fb5b9b9367b7c27560

What is your rclone version (output from rclone version)


Which OS you are using and how many bits (eg Windows 7, 64 bit)

Debian 10 x64 (Linode)

Which cloud storage system are you using? (eg Google Drive)

Google Drive

The command you were trying to run (eg rclone copy /tmp remote:tmp)

/usr/bin/rclone mount gcrypt-drive:directory /usr/local/media --daemon --vfs-cache-mode off --dir-cache-time 90m --read-only

The rclone config contents with secrets removed.

type = drive
client_id = (redacted)
client_secret = (redacted)
scope = drive
token = {"access_token":(redacted)
root_folder_id = (redacted)

type = crypt
remote = gdrive-drive:gcrypt
filename_encryption = standard
directory_name_encryption = true
password = (redacted)
password2 = (redacted)

A log from the command with the -vv flag

Do not have that yet


that is an old version of rclone, best to update to latest stable v1.56.0 and test again.

why do you think the issue is from rclone?
without a debug log, hard to know what is really going on.....

was this a one-time issue or is it reproducible?

perhaps that lack of free disk space is affecting jellyfin or some other function of the server.

as a test, at the same exact time you are having issues with jellyfin, have you tried to play the same media file direct from the mount, using vlc or other app?

The reason I'm using the version I am is for standardization purposes, but I will test going to 1.56.0 tonight.


Yes I have and it was fine, however not sure if it could be due to better error handling in VLC or any other media player. I had the debug window open at the same time and nothing stood out.

Is there a way to have the -vv rclone mount process write out logging to a file as a cmdline switch, or should I just redirect stdout to a file?

As a side note this is what I'm using to free space from the transcoding-temp in case free space is less than 5G:

#!/usr/bin/env bash

FREE=$(df -k --output=avail "$TCODETMP" | tail -n1)
if [[ $FREE -lt 5242880 ]]; then
        #less than 5GB
        rm -rf "$TCODETMP"/* >/dev/null 2>&1

if vlc plays the same media file fine at the same time jellyin has issues, not seeing how this is a rclone issue.

perhaps the transcoding is overloading the cpu or running low on memory.

what if you direct-play, do you still have problem?

fwiw, for media streaming, i only use read only rclone mounts , on windows, linux, even on a raspberry pi zero.
never had an low free space issues with read-only rclone mount

as for the log,
--log-level=DEBUG --log-file=/path/to/log/log.txt

Please close this, I'm an idiot and turned out to be the library itself. Re-scanning 22+TB takes a very very long time.

well, it has been two long years since you last posted.
that you have been an idiot only once, here in the forum, doing better than me :upside_down_face:

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