[Bug]: The first synchronization cannot be stopped and it is always in sync.

[lyiton]

What happened?

Let me first describe my scenario. I want to migrate from remotely-save to remotely-secure. I back up all files, then delete the entire vault(including configuration files), then download remote security, set up the S3 service. I set sync on save to every second, autorun to every 5 seconds, and run at 1 second after startup. Then I put all the files back into the vault. Then the synchronization started. I waited for half an hour, but the synchronization was still not completed. In fact, I don’t have many folders (1000, 1M in total). The synchronization process in the status bar is a bit strange. Normally it is 1/1000, 2/1000, 3/1000..., but my synchronization process is 1/1000, 2/9XX, 3/9XX..., the number to the right of "/" keeps changing.

My guess is that my first synchronization could not be completed because I set "synchronize when saving to every second, set autorun to every 5 seconds, and run at 1 second after startup."

After that, I deleted all the files, turned off all automatic synchronization, then reconfigured it, manually clicked synchronization once, and it was normal(1/1000, 2/1000, 3/1000...), and then I set up automatic synchronization.

What OS are you using?

Windows

What remote cloud services are you using?

S3

Version of the plugin

0.4.19

Version of Obsidian

1.4.16

Using password or not

• [ ] Yes.

Ensure no sensitive information

• [X] I ensure that no sensitive information is submitted in the issue.

[sboesen]

Hello, thanks for filing the issue and sorry you're experiencing issues syncing here. Will try to reproduce the issue locally and update if I need more clarifications.

[lyiton]

To provide a more helpful explanation, I attach the screenshot below. I have a total of 1113 files (1.51MB), but the plug-in has been requested 120,000 times, and the cumulative traffic is 22MB.

[sboesen]

Thank you, that helps! You mentioned you migrated from Remotely Save, did you experience these issues in Remotely Save as well or is this specific to Remotely Secure?

The synchronization process in the status bar is a bit strange. Normally it is 1/1000, 2/1000, 3/1000..., but my synchronization process is 1/1000, 2/9XX, 3/9XX..., the number to the right of "/" keeps changing.

I think this may be related to a recent change I made to the status bar, will investigate. I opened a new issue to track this (#46) separately.

[lyiton]

Remotely-save doesn't show the status bar information, so I'm not sure if this problem occurs in remotely-save.

One thing I want to add is that the question I asked above is that I set "Sync on Save (every 1 second), Schedule For Auto Run (every 5 seconds), Run Once On Start Up Automatically (sync once after 1 second of start up)", then I moved the file into Obsidian, and the problem occurred during automatic synchronization.

But since the synchronization has not been successful, I canceled the automatic synchronization of the plug-in, that is, "Sync on Save (not set), Schedule For Auto Run (not set), Run Once On Start Up Automatically (not set)", and then I move the files into Obsidian and manually click the arrow button to start synchronization. There is no problem with manual synchronization.

By the way, I would also like to add that the total number of my files is about 1,000, but my synchronization process is 1/1000, 2/1000, 3/1000,..., and it ends at 200/1000, but I check the storage Buckets and files have been uploaded. I guess the upload ends when it reaches 200 because of a calculation error caused by the default Concurrency of 5 (actually the upload is correct). I hope this problem can be improved.

[sboesen]

Thank you! I was able to reproduce the concurrency status bar issue and will track fixing it in #46.

and the cumulative traffic is 22MB.

Did you experience this type of traffic mismatch compared to the local file size using Remotely Save? Trying to narrow down if it's a result of a change I made to Remotely Secure or if it's existing code we'll need to rework.

Really appreciate your details/screenshots!

[lyiton]

The first video is about the process when I used remote-secure to set up automatic synchronization and an error occurred.

In the second video, I used remote-secure and manually synchronized it. There was no problem, but the concurrency error was displayed.

For the third video, I used remote-save and set up automatic synchronization, and there was no problem. Because remote saving cannot display the status bar information, I judge whether it is completed by the status of the arrow button. It can be seen that the automatic synchronization stops after a period of time. Remotely-secure is always in sync and cannot be stopped. It can be determined that this problem only occurs in remote-secure, but there is no such problem in remote-save.

https://github.com/sboesen/remotely-secure/assets/76651858/59daccad-25da-458b-82f9-10f93ebc1603 https://github.com/sboesen/remotely-secure/assets/76651858/726836b6-f45c-4e41-a225-b89c75023f20 https://github.com/sboesen/remotely-secure/assets/76651858/2cf7e51f-3a36-4b14-b085-e18e989bc79b

[sboesen]

I set sync on save to every second, autorun to every 5 seconds, and run at 1 second after startup.

Thanks for sharing those! Will review and try to reproduce with your config.

[MartinJDavis93]

Here, I can only mention that 15 of my friends, in addition to myself, have switched from 'Remotely Save' to 'Remotely Secure'. All of us resynchronized our vaults accordingly. I've 4 devices, and my friends have 2-3-4 devices, depending on the individual. The size of my vault is not large, 2.3 MB, with many notes, but I don't have a lot of attachments, so it's mostly simple markdown files taking up kilobytes. Many of my friends have attachments with PDF files, so their vaults are larger. Personally, I use Dropbox, but some friends use OneDrive. I am unaware of the number of their syncing devices.

We all configured the plugin and enabled autosync every 5 seconds, then synchronized the vault. I deliberately did this because I was curious to see if any issues would arise due to such a short synchronization interval (as I opened an issue requesting shorter time intervals for synchronization). I also had 'Sync on Save' enabled, but that's not important. I didn't encounter any problems. Synchronization took only a few seconds. I immediately turned off the synchronization display line, or it was already turned off by default; I don't remember. In short, I relied on the animation of the icon on the panel (I didn't check on the phone; it just synchronized, and that was it).

Perhaps it would have been more logical to start with manual synchronization first, and when the vault is synchronized, then enable automatic synchronization in the settings. However, I did it as an experiment. I told my friends that they could configure everything they needed from the start, even though they have all the parameters turned on/off, just like me. In the end, none of us had any synchronization issues. So maybe this problem is not systematic, or perhaps it's related to the synchronization service. I don't know. Maybe we were all just lucky. Although 16 people are not a bad sample, so I decided to report it so that you would be aware. None of us encountered this problem.

[kadisonm]

Perhaps it would have been more logical to start with manual synchronization first, and when the vault is synchronized, then enable automatic synchronization in the settings.

Honestly the whole process could be a bit more user friendly. The plugin should probably prompt the user to do an initial sync after auth first then suggest those settings.

[sboesen]

Although 16 people are not a bad sample, so I decided to report it so that you would be aware. None of us encountered this problem.

Thank you, that does help. Appreciate the details.

Honestly the whole process could be a bit more user friendly. The plugin should probably prompt the user to do an initial sync after auth first then suggest those settings.

Agreed, this is worth exploring. Similar to #39 but worth discussing in a new feature request.

[MartinJDavis93]

Perhaps it would have been more logical to start with manual synchronization first, and when the vault is synchronized, then enable automatic synchronization in the settings.

Honestly the whole process could be a bit more user friendly. The plugin should probably prompt the user to do an initial sync after auth first then suggest those settings.

I don't know, maybe you're right; it's hard to say. First and foremost, it need to determine whether this issue is systematic or genuinely individual. In the latter case, it will significantly complicate finding a solution. I think it's not worth complicating the display of additional parameters until after the user completes the initial synchronization. Perhaps it would be beneficial to implement a welcome window after installing the plugin, where recommendations of this nature are provided. Over time, if necessary, these recommendations can be easily supplemented. This approach to displaying information is used in Excalidraw. However, after each plugin update, the window repeats, causing some discomfort. This is likely unavoidable, as updating the plugin essentially involves reinstalling it. Therefore, in conclusion, I would still reject this option due to this nuance.

The most correct and simple solution, in my opinion, is to add a section in 'Redmi', somewhere near the top of the page, labeled 'Usage Recommendations'. All possible nuances can be mentioned there. And since the plugin installation page in Obsidian also shows users the Redmi page, they can easily access this information if they wish. It would clearly not be superfluous, and the developer could refer to it in cases where the user may not have been entirely attentive or chose to ignore the recommendations.

[kadisonm]

However, after each plugin update, the window repeats, causing some discomfort.

This could be avoided by checking if the user has already authenticated in the data.json.

[MartinJDavis93]

However, after each plugin update, the window repeats, causing some discomfort.

This could be avoided by checking if the user has already authenticated in the data.json.

I don't know, maybe so. After today's plugin update, I see updates for almost all plugin files, including data.json.

If it's possible, yes, it could be one of the options. But how satisfactory it is, let the plugin author determine. Personally, I think a section in Redmi is more than enough.

[kadisonm]

I see updates for almost all plugin files, including data.json.

The data should persist through updates. So yeah either a read me update or an initial install modal would work.

I still don't see harm in only displaying auth settings first and then prompting the user to configure settings after an initial sync. I mean a simple 'skip guided installation' could be added as well maybe?

I made a new feature request to discuss this #49

[MartinJDavis93]

I see updates for almost all plugin files, including data.json.

The data should persist through updates. So yeah either a read me update or an initial install modal would work.

I still don't see harm in only displaying auth settings first and then prompting the user to configure settings after an initial sync. I mean a simple 'skip guided installation' could be added as well maybe?

I made a new feature request to discuss this #49

However, I see. There is a high likelihood that the average user simply won't revisit the plugin settings after the initial configuration, even with a separate warning message. Most users only pay attention to messages or warnings when something stops working correctly. Additionally, this will add extra work for the author. If this issue is not purely individual or just some unforeseen error, then there is no necessity for this implementation at all. And if not, then yes, it'll need to find a way to address it. Until the problem can be reproduced, there is no point in such radical implementations. Well, that's my opinion.

[MartinJDavis93]

Although 16 people are not a bad sample, so I decided to report it so that you would be aware. None of us encountered this problem.

Thank you, that does help. Appreciate the details.

I'll also note that none of us use encryption.

[sboesen]

@lyiton can you share the test files/folders you used (if there is nothing sensitive in them) as an attachment in this issue? Thanks again for sharing those videos!

[lyiton]

Of course, these files are randomly generated by me and contain no sensitive information. I'd be honored if I could help you. test.zip