No, as I said in my earlier post, I copied a file to Google this morning (8-9 AM) and it did not show up in Plex after repeated scans. The 3:10 PM (15:10) is referring to the time that I ran your command "rclone ls "PlexDrive:Plex/TV Shows/Private Eyes/Season 03" Sorry for the confusion.
I tried something. I deleted the Private Eyes file (720) and added it with a newer version 1080 using the web interface of Google Drive (a different computer). I waited more than a few minutes and I then ran both commands (ls on the mount and the rclone) and they are not the same. One shows the old one and the other shows only the new file. Does that help?
Nifty.
I wonder if some regression crept in as I recreated your issue on Mac and on my Linux box.
Let me dig a little bit more.
@calisro - can you do a test on your side and see if you are seeing polling updates?
I just did a debug mount test:
felix 7629 7315 0 13:46 pts/0 00:00:00 rclone mount -vv GD: /GD2 --dir-cache-time 12h
and I copied a file up via rclone as it doesn't seem to matter how it is copied.
This looks odd to me:
I don't get why the lsf is showing hosts2 as a directory when it's a file.
Seems to work: I copied a file to my mount. Then waited a few and checked the remote directly.
root@:/data/Media# cp ~/sources.xml apk/
root@:/data/Media# rclone lsf robgs-cryptp:Media/apk/
Scripter-debug.apk
sources.xml
and then I deleted it from the remote itself and checked the mount and it was gone.
root@:/data/Media# rclone delete robgs-cryptp:Media/apk/sources.xml
root@:/data/Media# ls -al apk/sources.xml
ls: cannot access 'apk/sources.xml': No such file or directory
Should I test a different way?
root@:/data/Media/apk# rclone version
rclone v1.47.0-067-g9c6f3ae8-beta
- os/arch: linux/amd64
- go version: go1.12.5
If you can recreate it, i'd suggest you run with --dump bodies and see if you can see the file in the polling event query.
I'll redo that way and grab the bodies.
[felix@gemini GD2]$ rclone copy /etc/hosts GD:
[felix@gemini GD2]$ date
Thu 30 May 2019 02:04:26 PM EDT
[felix@gemini GD2]$ date
Thu 30 May 2019 02:05:07 PM EDT
[felix@gemini GD2]$ ls
2019 'Arq Backup Data' backup media UserUsageReport-20190517-1232.xlsx
[felix@gemini GD2]$
I'm not seeing any updates from polling.
root@:~# rclone lsf robgs-cryptp:Media/apk/
Scripter-debug.apk
root@:~# date
Thu May 30 14:09:23 EDT 2019
root@:~# rclone copy /etc/hosts robgs-cryptp:Media/apk/
root@:~# cd /data/Media/apk
root@:/data/Media/apk# ls hosts
hosts
My mount is set to --dir-cache-time 485h so it is definately the polling picking up mine.
2019/05/30 14:09:57 DEBUG : apk: invalidating directory cache
Thats a duplicate. That will impact the polling I believe. I bet if you cleanup the dups it'll work again for that directory/file.
Hmm, let me give that a try and see how it works. I've had the dedupe running and will retest after that.
So this is odd as I ran dedupe, don't see any issues there anymore, but the change doesn't pick up:
ba
{"newStartPageToken":"4777844","changes":[{"fileId":"1IefjgkY59uiHOHkArVAW9A1B2oOiI5yl","file":{"name":"hosts","mimeType":"application/octet-stream","parents":["0AC9RTGwjTUgOUk9PVA"]}}]}
0
No file is there:
'Arq Backup Data' backup media
[felix@gemini Test]$ rclone copy /etc/hosts GD:
[felix@gemini Test]$ ls
'Arq Backup Data' backup media
[felix@gemini Test]$ date
Thu 30 May 2019 07:47:14 PM EDT
[felix@gemini Test]$ ls
'Arq Backup Data' backup media
[felix@gemini Test]$ ls
'Arq Backup Data' backup media
[felix@gemini Test]$ date
Thu 30 May 2019 07:48:30 PM EDT
[felix@gemini Test]$ ls
'Arq Backup Data' backup media
file looks proper as well in the lsf:
[felix@gemini Test]$ rclone lsf GD:
Arq Backup Data/
backup/
hosts
media/
I don't get it.
If it's not in the polling API then it's on Google's side. Try different file names? Subdirectory?
Hmm. I went back to 1.46. Same thing as I tried a different file. Have to dig in a bit more as I've done the hosts file copy probably 1000 times in testing things so not sure what changed.
Can you try it on a non encrypted area? It does work on my crypted mount.
On my encrypted remote, I can see:
2019/05/30 20:35:36 DEBUG : : invalidating directory cache
That never happens on my non encrypted test.
Hmm. I can confirm its not working on my unencrypted remote. That's pretty odd.
So I feel less crazy. The OP is one of the rare folks using an unencrypted remote 
1 Like
I made an issue for it as the bug seems to be with a non encrypted remote and polling:
Good find I guess
Thanks for your help - I am glad that you found something - I thought I was going nuts