mirror of
https://github.com/floccusaddon/floccus.git
synced 2026-04-25 22:26:06 +03:00
[GH-ISSUE #572] hints for MANY bookmarks - what to do? #402
Labels
No labels
browser-specific
bug
correctness issues
enhancement
feature: Google Drive
feature: Linkwarden
feature: git
feature: nextcloud-bookmarks
feature: tabs
feature: webdav
help wanted
native-app
priority: high
priority: low
priority: medium
pull-request
question
question
stale
upstream
waiting for more information
wontfix
🙁 Not following issue template
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/floccus#402
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @drandreaskrueger on GitHub (Jun 16, 2020).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/572
What I already found out is this:
floccus showed
then I found this workaround for today:
Suggestion - Your floccus add-on can ask for permission to store more than 5 MB, read this https://developer.chrome.com/apps/offline_storage
I keep an eye on the nextcloud server "htop" - which is fine; and on the chrome "task manager" which is at 150-250 CPU for a very long time now.
What can I do with MANY bookmarks?
Is your feature request related to a problem? Please describe.
more than a decade of bookmarking ...
Describe the solution you'd like
either floccus or nextcloud is hitting some limits
Describe alternatives you've considered
reinstalling nextcloud but this time not via snap, because I read that snap causes programs to need more resources. but somehow this looks as if the main problem is in the client (chrome) not on the server (nextcloud).
What in your experience is the fastest and most stable browser to use when many bookmarks, for floccus?
Additional context
11000 - 19000 bookmarks. Not totally sure, a partial sync into a browser, and then export to HTML file, shows that 19081 times the word 'http' is in the sourcecode of that HTML bookmarks file. However, the nextcloud web interface says 116... on https://.../index.php/apps/bookmarks/ so I guess that means 11600 (and the nextcloud webinterface code needs a small change). Is it possible that a bug in floccus, or due to over the limit errors ... that duplicate bookmarks got introduced when syncing?
Anyways, the above is more a selection of questions, and suspicions, than a clear feature request. It's half way to a bug report anyways. Sorry for that. Perhaps this is useful nevertheless.
Keep up the good work. Much appreciate floccus. Good job!
@marcelklehr commented on GitHub (Jun 16, 2020):
Thank you for your feedback! I do have heard from people having trouble with more than 10000 bookmarks.
Ah, I will fix that. thanks for reporting.
For many (read: ALOT of) bookmarks, I generally recommend using the webDAV sync method, because it uses much less network than syncing with the bookmarks app. However, in this case, your bookmarks won't show up in the web UI.
If you do want to stick with the bookmarks app, you might be happy to know that only the initial sync time is proportional to the amount of bookmarks you have, as floccus indexes them all and builds a cache. Once that is done, sync time is proportional to the amount of changes and their depth in the bookmarks tree. That way, if you have no changes, it shouldn't take more than a minute. Come to think about it, I do know about one bottleneck that could be improved further to speed up regular syncs.
This is unlikely to be the problem, although snap does have numerous disadvantages in my book :)
The counting logic is rather new and there have been reports of it misbehaving, so, I wouldn't depend on it being accurate, atm.
I have had reports of this in the past, but I think those issues should be sorted out now.
If you're up for a bit of debugging, you could try the addon inspector. This will tell you what floccus is up to (in the console tab) as well as the currently running network requests (in the network tab).
Firefox
about:debuggingdebugorInspectbutton next to floccus entryChrome
chrome://extensionsDeveloper modedist/html/background.htmlbutton in floccus' entry next to "Inspect views: "@drandreaskrueger commented on GitHub (Jun 17, 2020):
Fantastic, that is very valuable information. Thanks for the quick reply.
Great. So I should look into this, right? "XBEL file in WebDAV share"?
Is that a single file? Doesn't that mean that always the whole 2 MB have to be transferred? Is it still faster than the mysql nextcloud bookmarks app? What about concurrent read write attempts from different browsers? Is the XBEL file locked during one sync? Sorry for all the questions, is there s.th. I could read? Thanks.
Hmmmm ... the few times I tried that, it was super slow. So that might not be a big loss.
Sounds good. One time time usage is no big problem.
Good to know. That had been my hope for syncing the bookmarks from my mobile browser. Enable a brave sync between mobile and desktop, and then do a floccus sync between desktop and cloud. Not a good idea? How else to get my mobile bookmarks off the android? (*) Thanks.
Actually, I could switch it on and off manually, right? Either brave sync or floccus sync. Would that work?
(*) this? https://play.google.com/store/apps/details?id=com.kiwibrowser.browser can it import existing bookmarks?
Yes snap was great for a quick start. But I have already wiped it of the machine. Let's start again this time step by step, manually :-)
Nice one. Didn't know it existed.
found it. That will help. Thanks!
Using three different add ons, I could reduce the number of duplicates and dead sites by 10000. Now less than 9k bookmarks in total, should work better.
@marcelklehr commented on GitHub (Jun 17, 2020):
Yes, it's a single file and floccus employs a lock file mechanism. Usually even if the file is large (and we're talking about single digit megabytes here, so downloading that shouldn't take too long) this method is faster because you only have a fixed number of network requests and nearly no server-side computation.
Different browsers employ different native bookmark syncing mechanisms. Firefox is known to change bookmark ids when it syncs bookmarks, which causes trouble for floccus. Turning sync on and off will not fix this. I have no experience with other browsers' native sync, though. That message is more of a warning, i.e. if you want to try that, have backups (which you should always have when syncing anyway) and be prepared that things will break.
(Also, on initial sync floccus will pull upstream bookmarks and merge them with what you have locally)
@marcelklehr commented on GitHub (Jun 17, 2020):
Would you mind finding out with the instpector what exactly is taking so long? I have a theory.
@drandreaskrueger commented on GitHub (Jun 17, 2020):
Oh I am sorry, I have purged that nextcloud installation. So for now the answer is: Sorry, no.
Once I have it up and running again (might take a while) I will try what I can find out for you.
@drandreaskrueger commented on GitHub (Jun 17, 2020):
Oh ouch, yes I can imagine that to be a source of trouble.
Idea: Floccus could perhaps ignore the "bookmark id" completely?
And instead use a hash of the whole bookmark (title and url and whatever else is stored) to identify whether that one bookmark is unchanged, or whether it needs syncing. And a hash of all hashes (or even a Merkle tree) could answer whether any bookmark had been changed since last sync.
Then firefox can change the id, with no effects.
@drandreaskrueger commented on GitHub (Jun 17, 2020):
thx for those instructions. Will try that.
@marcelklehr commented on GitHub (Jun 17, 2020):
Ah, yes. I'm already using Merkle trees for diffing. The IDs are important for moving items, though. Without those it's really difficult to tell where the user moved a folder, if that folder has also been changed.
@drandreaskrueger commented on GitHub (Jun 17, 2020):
instead also hash the folders perhaps?
Then a location in the tree can be expressed with a sequence of hashes (instead of that unreliable id)?
@marcelklehr commented on GitHub (Jun 17, 2020):
What happens if the folder contents have changed? I still want to move that folder even if its name and contents have changed.
@drandreaskrueger commented on GitHub (Jun 18, 2020):
not sure I understand what you mean by "move".
Why not let it "disappear" (i.e. delete) at location A, and "create" a completely new branch in location B? At some level of user changes, giving up on tracking all of them might be easier, no?
But sorry for the curious questions, you are the expert on your software, I just had some ideas - but all based on my dangerous half-knowledge. So don't get distracted by me ;-) You will know what's best.
Thanks for your amazing responsiveness, hope my feedback was valuable somehow.
@github-actions[bot] commented on GitHub (Mar 21, 2023):
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.