RClone mount to Dropbox - Scan with CLRMamePro

Hi everyone, and thankyou for reading :slight_smile:

So, I'm using Dropbox Enterprise, with a mount like this:

rclone mount Dropbox:Shared R: --cache-chunk-size=768M --cache-workers=10 --buffer-size=512M --cache-writes --cache-db-path=e:\rclone-dropbox\ --cache-dir=F:\RClone-Dropbox --allow-other --vfs-cache-mode full -v --dropbox-batch-mode async --tpslimit 10 --tpslimit-burst 10 -P --transfers=20 --checkers=20 --dropbox-chunk-size=150M --max-backlog=99999999 --dropbox-batch-size=500 --dropbox-batch-timeout=30s

Rclone version is (but this problem has been there for as long as I have tried, with all versions):

rclone v1.55.0-beta.5333.d65916f9a.fix-dropbox-batch-sync

  • os/type: windows
  • os/arch: amd64
  • go/version: go1.16.2
  • go/linking: dynamic
  • go/tags: cmount

Anyway, the problem I'm experiencing, is that using ClrMamePro to "scan" rom-files just doesn't work. It seems stuck on the "Finding unneeded files"-phase.
If I copy the exact folder to my local computer or smb/cifs-share, it scans just fine.

Also, here is the kicker. It's not consistent. It seems to work just fine for smaller sets, but it fails (and just loops) on larger ones.

(Yes, this is technically "copyrighted stuff", but it is absolutely ancient, so.. I hope this is not immediately removed)

Logfiles are placed here, due to their size (--logfile and --log-level DEBUG appended)

mega dot nz/folder/MCRQwZiD#XwmWpJEPj4kgNDw5t-vpbg

hello and welcome to the forum,

as per the debug log
NOTICE: --allow-other flag does nothing on Windows

did not see the config file?
the reason i ask for it; based on your command, you are using the buggy, depreciated, never left beta, cache remote. if true, i suggest to remove that and test again.
--cache-db-path, --cache-workers,--cache-chunk-size - these are for the cache remote

about the nonworking_rclone.log, did not see any ERROR in it?
post an example filename that is causing problems

Hi, and thanks for the very fast reply. Appreciate it.

Ok, lesson learned, never just assume the commandline you got from "someone else" is working :wink:

New commandline: (I just removed all options and so on to atleast be sure it's not that messing with me here.)

rclone mount Dropbox:Shared R: --log-file=e:\rclone.log --log-level DEBUG

And, I don't really have a filename that fails, I do see some repetition here though.

ClrmamePro scans alphabetically from what I can see. However, every now and then, it apparently restarts the scan from the top.

Top being: 01.01.95-Blackthorne_Update_010195-UNT

Example:
01.09.95-Sorian_Wars_Episode_1_The_Death_Mask-TRSI
01.12.95-The_Legend_of_Evil_Dragon_CRACKFIX
01.09.95-Destroy_Mr_McKee [!]
01.17.95-Microsofts_Complete_Baseball_1994_Edition_DEMO_for_Windows-AVG

When it comes to

03.12.95-Master_of_Orion_CDRom-LNS

it just never seems to go any further, and is stuck there. (and it scans really fast through the structure repeatedly)

Nothing special about that folder as far as I can see.

(new log uploaded, same location)

sure,

that software, it only scans filenames or data from inside the file and/or metadata such as modtime or what?

that rclone log you posted did not have any errors in it, as far as i can tell.
so look into the logs of that software for errors?

now that we have a debug log and an specific filename, we have experts who can look into that rclone log and see what i missed.

Clrmame has no logfile really (well, of the operaton, which we need here atleast)

It scans the folders first, and then it's supposed to scan the files inside, checksumming them and looking inside archives if so is configured.

It's mainly used for keeping your MAME-set up to date, but there are (as shown) other uses for it aswell.
mamedev dot emulab dot it/clrmamepro/ would be the homepage for more info.

if you have software that scans inside a file, should add --vfs-cache-mode=full.