[itimpi]

Not sure what is going wrong. The encryption string should not change between runs (unless you force a reset) - and there should only be a single occurrence of the @ symbol that is used to separate the encrypted part of the name from the plain text part (although it will occur in both the folder and file name parts). Does the file that causes the error exist in DropBox on your local PC? Does the 3.2 release work OK? If so I am even more puzzled as the code that generates file names has not changed for this beta release.

Can you look at the calibre2opds configuration file on your machine to see if it is storing a value for 'SecurityCode'. If possible it would be useful if you could raise a bug report and provide a copy of both the configuration file and the log.

Just as a check - does everything work as expected if you do not select the option to encrypt the file names?

I will do some specific testing with DropBox to see if I can reproduce your symptoms. I can with a one line source code change alter the @ to a different character, although my testing suggested it should not cause a problem.

Having said all the above the whole purpose of beta releases is to get some wider testing so that such issues can get resolved.

EDIT: I have just run a test and reproduced the double @ symbol. This should definitely not be happening - and will explain why a catalog is not working properly. I need to work out what I changed that had this side-effect since I last tested encrypted files. Hopefully it will be a trivial fix and the encryption key changing between runs is related. I will upload a fixed build as soon as I identify the cause.