Session buddy backup too large, causes tab to crash.

[chris lee]

Wondering if there's any solution for this issue i just ran into.

I did a large backup of sessions before I went to reinstall my chrome to see if it solved some other issues I had.

Trying to import the backup is basically impossible as after a certain point, I think it runs out of memory and crashes.

My old old backup which is smaller can be parsed eventually and is working fine, but newest backup is simply too large so it just crashes the tab.
What can I do about this?

[Atul]

same thing happened to me, I just broke the big JSON file into smaller files and imported one by one. It was a minor hassle but it worked.

[Kamran Chohan]

Atul, How did U do it? Can U please teach us ?

On Sun, Sep 30, 2018 at 1:36 PM Atul <atul...@gmail.com> wrote:

same thing happened to me, I just broke the big JSON file into smaller files and imported one by one. It was a minor hassle but it worked.

--
You received this message because you are subscribed to the Google Groups "Session Buddy Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sessionbuddy-dis...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bob walter]

Yeah I'd like to hear how you did that. I don't mind doing some legwork if I can get my backup up and running again.

[Atul]

It was just manual work of cutting the json file into smaller files via an editor and saving them separately so that the individual files are small enough size and then importing them one by one. My backup json file was 139 MB. I just copied the main parent object structure from backup json into a new json file first, and then by searching saved sessions by "name" string on the backup file, I copied the content of that main object into the new json file and repeating the process so that the new json file had 10-12 saved sessions and was about 15 MB in size and saved it. That was file no.1. I repeated the process so that 139 MB data was cut into smaller file, which was about 12 files of 11-15 MB each. I am sure SB can import a bigger size file but did not want to risk it.  

[bob walter]

I've imported at least 40MBs before though it takes a while. What was the editor that you used? I'm currently using notepad++ but my file is so big that it's kind of cumbersome to manipulate it.

[Atul]

I use Sublime Text, which is just a blessing. Yeah keeping it around 15 MB will be a faster importing process imo.

[bob walter]

I managed to finish up with notepad++ by the time you replied, but thanks for the replies to bounce ideas off of. I figured out the issue I was having when I was trying to transplant sessions was that I was not putting the right amount of spaces which was causing session buddy to not recognize my sessions. I hope they come up with a different way for backing up sessions eventually cause of the memory limitations of importing, which I didn't know about. At least the responses will be around for anyone else who runs into the same problem.

[Atul]

Congrats for the successful recovery lol. Yeah browser memory limitations affects every session manager extensions once the file gets too big. Happened to me on One-Tab as well but SB is far better options due to it's fluidity and functionality. The only pre-emptive process of making it easier from the get go, it seems, is to manually select few saved sessions in the exporting option and create small size files from the beginning rather than (or with addition to) creating a huge master back up file. At least that's something. 

[Live for Technology]

I've posted about this just a couple months ago from this one folks need to do better searching on these forums to save themselves a lot of time.  With that said I'm surprised you all are wasting time splitting json files when all it takes is restoring (after identifying since their docs are incorrect) the SINGLE sqlite database file to restore (with Chrome closed) - assuming you have file-level (or shadow copy) backups running.  If done properly, ALL SB DATA is restored, sessions, settings, etc. in the matter of a few seconds.  If, however, you do not have any system/drive level backups but for some reason cared only about SB session backups and have that - then yes, because of how they coded the loading loop it flat out exhausts available resources and crashes if the backup file is larger than approx. 40mb and will never succeed as you all have found unless a hacky method of file-splitting is employed.  Again it takes mere seconds to fully backup/restore 100% of all SB data and settings if you are backing up your Chrome "user data" profile folder.

Should their own backup/restore in the app work?  Hell yes.  I along with probably a few zillion of their users have either posted here or directly contacted them and received replies basically finger-pointing at the Chrome browser architecture as the reason why their own code not only does not work, but does NOT more importantly have error handling written to handle the crash - and as a DEV myself you CANNOT blame Chromium for your extension crashing without even telling the operator why the error occurred and at what point in the code which is just basic coding 101.  Their responses I have seen have never indicated they even cared that it was occurring to everyone, let alone indicated any planned action they were taking to even improve the error handling (assuming they cannot simply code the loop to read in CHUNKS at a time as users have now been forced to do manually).  Hence, I'll personally keep using it but just ensure I am taking regular offline profile backups of the SB database so I simply bypass their broken routines all together.

As for general Sessionbuddy DEV efforts though I seriously now hesitate to contribute any more $ to this product effort since even their basic blog hasn't had a single update in well over a YEAR, their "DEV road map" has also not been updated in 18+ months and even then, conveniently contains NOT A SINGLE DATE, either past or forecasted making it the equivalent of "yea we're working on stuff....don't ask us when" yet they continue to ask for DEV dollars and claimed they would be transparent in their efforts (and leave up posts indicating there actually ARE some active efforts.  Does anyone outside of their own DEVs have any firsthand knowledge whatsoever as to what those efforts are?  Have they have even written a single line of code on this product over the course of EIGHTEEN months that not a single update on ANYTHING has been posted?!?  (Whether to even just patch existing version issues let along towards the new major release codebase)

I mean, I've been wating YEARS for a simple 2-3 color dark CSS theme to stop being blinded at night anytime I use SB. You'd think 2 full YEARS into the "v4 roadmap" perhaps even just a tiny feature like CSS dark could have been released into the current codebase just to give their users a tiny taste of things to come, and so we know they are still alive.  :)

[Jay]

Hey mate, thanks for your valuable insights here! Would you be up for sharing where I can find the single sqlite database file you mentioned?

[user102...@gmail.com]

Thank you all for the tips.

I also periodically backup the SQLite file,

It should be located in:

C:\Users\Protools\AppData\Local\Google\Chrome\User Data\Default\databases\chrome-extension_edacconmaakjimmfgnblocblbcdcpbko_0

There should be normally 1 file called "1" without extension. I usually backup it and rename it by the date.

You could also use rsync if you have some experience or another backuping software (even windows own backup or file history should do). you can try freefilesync/realtimesync for windows.

I'll sketch up a script for split/join restoring large sessionbuddy json backup files when I'll have some spare time and post it here.

also might try sketching a script for converting the sqlite database to json for easier parsing and editing before restore.