vrtmrz / obsidian-livesync

MIT License
5.13k stars 167 forks source link

error with chunks timing out during sync #505

Open shaver opened 1 month ago

shaver commented 1 month ago

Abstract

The synchronisation hung up immediately after connecting.

Timeout errors checking for updated chunks

Expected behaviour

Actually happened

Synchronization gives errors about chunks, and shows timeouts in the log. The database connection can be verified successfully, and my other device doesn't report the issue.

Reproducing procedure

Trigger "Verify All"

Note: If you do not catch the reproducing procedure, please let me know the frequency and signs.

Report materials

If the information is not available, do not hesitate to report it as it is. You can also of course omit it if you think this is indeed unnecessary. If it is necessary, I will ask you.

Report from the LiveSync

For more information, please refer to Making the report.

Report from hatch ``` ---- Obsidian info ---- Navigator: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) obsidian/1.6.5 Chrome/124.0.6367.243 Electron/30.1.2 Safari/537.36 FileSystem: insensitive ---- remote config ---- cluster: n: "1" cors: credentials: "true" origins: app://obsidian.md,capacitor://localhost,http://localhost chttpd: bind_address: 0.0.0.0 enable_cors: "true" max_http_request_size: "4294967296" port: "5984" require_valid_user: "true" admins: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷 vendor: name: The Apache Software Foundation feature_flags: partitioned||*: "true" chttpd_auth: hash_algorithms: sha256, sha require_valid_user: "true" indexers: couch_mrview: "true" prometheus: additional_port: "false" bind_address: 127.0.0.1 port: "17986" httpd: WWW-Authenticate: Basic realm="couchdb" bind_address: 127.0.0.1 enable_cors: "true" port: "5986" smoosh: state_dir: ./data couch_httpd_auth: authentication_db: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷 secret: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷 authentication_redirect: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷 couchdb_engines: couch: couch_bt_engine couchdb: database_dir: ./data max_document_size: "50000000" uuid: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷 view_index_dir: ./data ---- Plug-in config --- version:0.23.23 remoteType: "" useCustomRequestHandler: false couchDB_URI: self-hosted(HTTPS) couchDB_USER: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷 couchDB_PASSWORD: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷 couchDB_DBNAME: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷 liveSync: false syncOnSave: false syncOnStart: false savingDelay: 200 lessInformationInLog: false gcDelay: 0 versionUpFlash: "" minimumChunkSize: 20 longLineThreshold: 250 showVerboseLog: true suspendFileWatching: false trashInsteadDelete: true periodicReplication: false periodicReplicationInterval: 60 syncOnFileOpen: false encrypt: true passphrase: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷 usePathObfuscation: true doNotDeleteFolder: false resolveConflictsByNewerFile: false batchSave: false batchSaveMinimumDelay: 5 batchSaveMaximumDelay: 60 deviceAndVaultName: "" usePluginSettings: false showOwnPlugins: false showStatusOnEditor: true showStatusOnStatusbar: true showOnlyIconsOnEditor: false usePluginSync: false autoSweepPlugins: false autoSweepPluginsPeriodic: false notifyPluginOrSettingUpdated: false checkIntegrityOnSave: false batch_size: 50 batches_limit: 50 useHistory: true disableRequestURI: true skipOlderFilesOnSync: true checkConflictOnlyOnOpen: false showMergeDialogOnlyOnActive: false syncInternalFiles: false syncInternalFilesBeforeReplication: false syncInternalFilesIgnorePatterns: \/node_modules\/, \/\.git\/, \/obsidian-livesync\/ syncInternalFilesInterval: 60 additionalSuffixOfDatabaseName: 538aaaf492859f03 ignoreVersionCheck: false lastReadUpdates: 23 deleteMetadataOfDeletedFiles: false syncIgnoreRegEx: "" syncOnlyRegEx: "" customChunkSize: 50 readChunksOnline: false watchInternalFileChanges: true automaticallyDeleteMetadataOfDeletedFiles: 0 disableMarkdownAutoMerge: false writeDocumentsIfConflicted: false useDynamicIterationCount: false syncAfterMerge: false configPassphraseStore: "" encryptedPassphrase: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷 encryptedCouchDBConnection: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷 permitEmptyPassphrase: false useIndexedDBAdapter: true useTimeouts: false writeLogToTheFile: true doNotPaceReplication: false hashCacheMaxCount: 300 hashCacheMaxAmount: 50 concurrencyOfReadChunksOnline: 100 minimumIntervalOfReadChunksOnline: 100 hashAlg: xxhash64 suspendParseReplicationResult: false doNotSuspendOnFetching: false useIgnoreFiles: false ignoreFiles: .gitignore syncOnEditorSave: false pluginSyncExtendedSetting: {} syncMaxSizeInMB: 50 settingSyncFile: "" writeCredentialsForSettingSync: false notifyAllSettingSyncFile: false isConfigured: true settingVersion: 10 enableCompression: false accessKey: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷 bucket: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷(0 letters) endpoint: Not configured or AWS region: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷(4 letters) secretKey: 𝑅𝐸𝐷𝐴𝐢𝑇𝐸𝐷 useEden: false maxChunksInEden: 10 maxTotalLengthInEden: 1024 maxAgeInEden: 10 disableCheckingConfigMismatch: false displayLanguage: "" enableChunkSplitterV2: false disableWorkerForGeneratingChunks: false processSmallFilesInUIThread: false notifyThresholdOfRemoteStorageSize: 0 usePluginSyncV2: false usePluginEtc: false handleFilenameCaseSensitive: false doNotUseFixedRevisionForChunks: true showLongerLogInsideEditor: false sendChunksBulk: false sendChunksBulkMaxSize: 25 useSegmenter: false useAdvancedMode: true usePowerUserMode: true useEdgeCaseMode: false configPassphrase: "" preset: "" syncMode: ONEVENTS dummy: 0 ```

Obsidian debug info

Debug info ``` ```

Plug-in log

We can see the log by tapping the Document box icon. If you noticed something suspicious, please let me know. Note: Please enable Verbose Log. For detail, refer to Logging, please.

Plug-in log ``` ```

Network log

Network logs displayed in DevTools will possibly help with connection-related issues. To capture that, please refer to DevTools.

Screenshots

If applicable, please add screenshots to help explain your problem.

Other information, insights and intuition.

There are newer versions on my iPad, and my Windows machine is failing to sync. The specific files that are newer on the iPad seem to be the ones mentioned in the log errors.

livesync_log_2024-10-01.md

myhrmans commented 1 month ago

Running into the same issue. Did you manage to fix this?

myhrmans commented 1 month ago

Solved by downgrading back to 0.23.21

shaver commented 1 month ago

Probably a dumb question, but how do I go about downgrading?

myhrmans commented 1 month ago

Not at all. I had to google myself.

Go here and download the main, manifest and styles file. https://github.com/vrtmrz/obsidian-livesync/releases/tag/0.23.21

Go into your obsidian folder -> .obsidian\plugins\obsidian-livesync and replace the files there.

vrtmrz commented 1 month ago

Thank you for opening the issue! And I am sorry for the rough and short reply. I am on the mobile phone now.

Your logs are so helpful to me! That indeed indicates that chunks cannot be waited. I think it probably get better if enabling fetch chunks on demand on the advanced -> transfer tweaks (I think that it would be enabled in default).

I suspect a few points, but before all, it has gotten a bit complicated now. Hence I rewriting to separate the features from the main now. Sorry for your inconvenience, but let me allow to spend a bit more time.

P.S. using BRAT is a quite easy method to install a specific version.

shaver commented 1 month ago

Thank you both! I will have to figure out how best to downgrade on my iPad and iPhone; probably some Files app shenanigans.

I had fetch chunks on demand enabled on the device that the logs are from, but not on the other one that's currently in the sync set. Enabling on that (iPad) didn't seem to help, FWIW. I still have updates on each of the desktop and iPad that aren't visible in the other.

vrtmrz commented 1 month ago

Thank you for your try and cooperation! Is any device enabled the Send chunks in bulk? This is the most suspecting (and unfortunately I had enabled on default once) feature. If enabled, please try Resend on the maintenance pane on each device, and disable the Send chunks in bulk again. It may complement missing chunks in the remote database.

shaver commented 1 month ago

Neither have that set now, and I don't recall ever having done so. (I don't have latency concerns with my networks.)

vrtmrz commented 1 month ago

Thank you again and excuse me! I will investigate it tomorrow on my desktop!

shaver commented 1 month ago

In case it's helpful, one of the errors I get repeatedly on my desktop is:

10/14/2024, 10:53:06 AM->Scanning hidden files.
10/14/2024, 10:53:06 AM->Some chunks are not exists both on remote and local database.
10/14/2024, 10:53:06 AM->Could not fetch chunks from the server. 
10/14/2024, 10:53:06 AM->Exception raised while retrieving chunks
10/14/2024, 10:53:06 AM->Error:Failed: CollectChunksInternal
10/14/2024, 10:53:06 AM->Chunks of .obsidian/workspace-mobile.json (i:f:0c7d) are not valid.
10/14/2024, 10:53:06 AM->Missing chunks: 
10/14/2024, 10:53:06 AM->STORAGE <-- DB:.obsidian/workspace-mobile.json: written (hidden, overwrite) Failed
10/14/2024, 10:53:06 AM->Error:File not found on database.:.obsidian/workspace-mobile.json

"mobile" is the name I gave my phone, from which I have uninstalled Obsidian (which might be why it's missing?).

@vrtmrz if it's helpful, I can provide you privately with a copy of most of my Vault, assuming you'll delete it promptly when you're finished debugging!

vrtmrz commented 1 month ago

I finally understood. Under normal circumstances, file transfers were always guaranteed to send chunks prior to the metadata, but when Send chunks in bulk was enabled, this was broken. Thanks to everyone for the logs and information!

Send chunks in bulk will be removed in v0.24.0 and we will only be asked if we want to do it during rebuilding the remote. (This was originally intended to improve speed of that).

For now, disabling Send chunks in bulk will resolve this circumstance.

And, v0.24.0 is now RC3. Please wait for a while, or you can try that by BRAT!

shaver commented 1 month ago

Hmm, I never had send chunks in bulk enabled, to my knowledge. I did manage to resolve the issue by forcing some rebuilds, though.

vrtmrz commented 1 month ago

I regret to say this but there has been a notable decision mistake. That feature had been enabled by default from v0.23.21 to v0.23.22. And it will not back to be disabled automatically. Because of at the time, I did not realise why. So, I tried to avoid letting automatic cause unexpected again.

Now the reason is clear, so the feature will be removed at v0.24.0.

shaver commented 1 month ago

Ah, OK. It showed as being disabled when I checked, but if it had done some sort of damage when automatically enabled, then I wouldn't have known. Thank you for your reply, and all your work on this wonderful software!