[durd]

I think you found an interesting "feature" of the Dropbox api. Seems that if the folder you are trying to delete contains too many files it will just refuse to delete it. Perfect. Looks like I'll have to add some logic on the Dropbox VFS end of things to delete folders recursively up to the root folder - will make this a longer operation. Adding this to github and will get to it soon.

Yay!
For reference, although i think its easy to get the number of files directly from python, ive seen backups between 10 000 and 12 000 files, and i have unchecked the Backup thumbnails option.

You are correct about the speed of the dropbox upload process. It is slow. Their Python API doesn't have any mechanism for batch uploading, or even uploading things by folder, just one file at a time. Since it's REST based you have to wait for the upload and then do it again. To be honest - if you have a system that can support the regular Dropbox client you're almost better off installing it and using that as a client. The integrated Dropbox target is meant for stuff like OpenELEC or small systems where this isn't feasible. Personally I back up my XBMC host to a NAS and the NAS then syncs with Dropbox. Makes the backup happen really fast locally and then regular Dropbox client can sync from there.

Yeah, i thought it would be this, else it would have worked properly from the start or been fixed along the way.
What about incremental backups? Or this could go together with the Git issue to compress or package the backup to one file.

Ill look into getting a proper Dropbox client for my rpi. My NAS runs FreeBSD which isnt supported except via API...

Also, thanks for the awesomely quick response