I accepted Joplin Desktop App's notice of availability to download (for macOS Big Sur) v. 2.8.3.
I downloaded this pre-release version, installed it, and then opened Joplin.
For the first time ever, Joplin would not open correctly. The first time I ran it: no window opened. The second, and subsequent times I ran it a blank window opened and nothing appeared, even as I waited for a couple of minutes. I tried quitting Joplin by right-clicking on its Dock icon, but nothing happened. ("Force Quit" menu item never appeared, but "Quit" would not quit Joplin.)
I opened Activity Monitor and forced Joplin to quit.
(I see that there's already a 2.8.4 pre-release version that should soon become available as an installable download.)
1 Like
Please try again with 2.8.4. The version before that indeed didn't work.
1 Like
I believe that Joplin 2.8.4 (prod, darwin) broke the Kanban plugin.
Logger.ts:219 10:02:20: PluginRunner: Error: Plugin com.github.joplin.kanban: More than 50 API calls are waiting - aborting. Please consider queuing the API calls in your plugins to reduce the load on the application.
at BackOffHandler.<anonymous> (BackOffHandler.ts:73)
at Generator.next (<anonymous>)
at /Applications/Joplin.app/Contents/Resources/app.asar/services/plugins/BackOffHandler.js:8
at new Promise (<anonymous>)
at __awaiter (/Applications/Joplin.app/Contents/Resources/app.asar/services/plugins/BackOffHandler.js:4)
at BackOffHandler.wait (BackOffHandler.ts:65)
at PluginRunner.<anonymous> (PluginRunner.ts:163)
at Generator.next (<anonymous>)
at /Applications/Joplin.app/Contents/Resources/app.asar/services/plugins/PluginRunner.js:8
at new Promise (<anonymous>)
Is there already a bulk api and I have overseen this one or will there be one in the near future?
As an example, I need the tags of X notes in a plugin, at the moment I need to send X API calls to get the tags, because I can't include multiple ids for the query of the tags.
Thanks yet again for another great update @laurent, the performance improvement in note switching is quite noticable.
Regarding the Plugin throttling, i did some tests, and found out that most mentioned plugins (I use them myself) are easily throttable:
- Quick Links seems to be fine
- Note Tabs is mostly fine, but can still get throttled
- Note Link System gets throttled easily
- Outline gets throttled easily
- Note Overview is unusable
I understand why this feature needs to be implemented (although i feel like that technical limitations shouldn't be a thing), but apart from some more fine tuning, I think there should be an option to disable it (perhaps in the Advanced Plugin Settings, with a big disclaimer "Disable at your own risk etc"), and maybe optionally a text box to let each user decide how many API calls to permit (looked around the code a little and saw that the logic is to permit up to 200 calls per 10 sec without restrictions at the moment). What are your thoughts on this take?
The goal is to set it up so that it works with all existing plugins except the faulty ones, so there won't be any advanced options.
Ok I see the Kanban plugin makes a crazy number of calls simultaneously and then stops. Maybe there's a need for allowing temporary bursts of requests since those aren't a huge issue for performance and battery life.
1 Like
Maybe we don't need pagination for plugins?
I bet most of these plugins are just trying to load all tags or all notes, something like this.
You could say that pagination is supposed to reduce memory consumption but I'm pretty sure plugins just shove all the data into a single array anyway. (I do this in the inline tags plugin for instance.)
Most likely we'll always have pagination because retrieving an unlimited number of notes in one query is likely to cause problems somewhere, whether it's the db driver, or plugin service, or with the plugin itself. It'd be a large blob of data that has to go through many layers. With pagination, it forces the plugin to stream that data in chunks of reasonable size and that's more manageable. We could probably increase the page size though.
However, no matter the optimisation, there will still be faulty plugins that make too many requests and end up crashing the app, and in the short term that's what I'm trying to prevent. Maybe the throttling idea is not the right approach. The difficulty is that I can't quite narrow down what pattern of requests could end up freezing the app, and what is fine.
I am also seeing this error on the Note Overview plugin. I am not sure if this was occurring previously or if it is new. cc/ @JackGruber
Error
Logger.ts:219 08:36:38: models/Setting: Could not save settings Error: Error: SQLITE_CONSTRAINT: UNIQUE constraint failed: settings.key: INSERT INTO `settings` (`key`, `value`) VALUES (?, ?): plugin-io.github.jackgruber.note-overview.updateOnSync,yes
at DatabaseDriverNode.sqliteErrorToJsError (/Applications/Joplin.app/Contents/Resources/app.asar/node_modules/@joplin/lib/database-driver-node.js:23)
at JoplinDatabase.sqliteErrorToJsError (database.ts:46)
at JoplinDatabase.<anonymous> (database.ts:150)
at Generator.throw (<anonymous>)
at rejected (/Applications/Joplin.app/Contents/Resources/app.asar/node_modules/@joplin/lib/database.js:6)
at processTicksAndRejections (internal/process/task_queues.js:95)
log @ Logger.ts:219
Warning
(I am getting this every 1 sec, so have lots and lots! Each has a different note ID)
08:39:22: BackOffHandler: Plugin io.github.jackgruber.note-overview: Applying a backoff of 1 seconds due to frequent plugin API calls. Consider reducing the number of calls, caching the data, or requesting more data per call. API call was: joplin.data.get (3) ['notes', 'XXXXXXXXX', 'tags'] {fields: 'id, title, parent_id', limit: 50, page: 1} [Wait count: 1]
Another thing I noticed was that my log.txt file had grown to over 5GB when I did a back up to install this version. I'm guessing things like this running every second had filled it up. My actual data was only ~50mb. Not sure if that's a feature or a bug, but thought I'd mention it 
I think I will change the restrictions so that it's much more permissive, and that might be enough to stop the faulty plugins without affecting at all the regular ones.
Something like max 5000 simultaneous calls, and only throttle to 100ms between calls instead of 1s. Then we'll see if we still get reports of frozen apps, and if we do we can adjust the settings further.
Do you have a flags.txt in your profile directory? If so you might want to delete it so that the app stops logging to file the plugin warnings.
Even if only 100 ms is throttled, there will be problems/delays with my noteoverview plugin.
To generate a overview with tags for each note
- Send search query, and get a list of 100 Notes (2x API call with 50 notes on each page, 100 ms)
- Get the assigned tags for the 100 Notes (100x API calls for receiving the tags, 10 seconds)
- Update note (1x API call 100 ms)
For the example, it would take over 10 seconds for the note to be updated 
1 Like
Yes but the 100ms delay only applies after x numbers of calls. Currently the first 200 calls get an immediate response, and maybe we can also increase this to eg 1000 to ensure most plugins aren't throttled.
I can confirm that note switching and deleting (using the tabs plugin) appears to be much faster. Thanks everyone!
I have had that before, but it I don't at the moment (at least I dont think I do). It would be at this level, correct?
Just to report that the profile switching is working very nicely on my Linux Mint system now the restart changes have been made.
1 Like
Actually I've just realised the warnings would be logged anyway, regardless of flag settings, and since you have a lot of plugins this log file is indeed going to grow fast with this prerelease. Hopefully with the next one and improved throttling settings it won't be an issue anymore.
Build on macOS not working.
macOS: macOS Monterey Version 12.3.1 (M1)
What I did after downloading the source code from here:
cd joplin-2.8.3
yarn
cd packages/app-desktop
export PYTHON_PATH=/usr/local/bin/python # Python 3.9.12
# Added ```from importlib import reload``` because it was giving errors while building
code /Users/krishna/Downloads/joplin-2.8.3/packages/app-desktop/node_modules/dmg-builder/vendor/dmgbuild/core.py
yarn dist
Logs:
➜ app-desktop yarn dist
[12:18:49] Using gulpfile ~/Downloads/joplin-2.8.3/packages/app-desktop/gulpfile.js
[12:18:49] Starting 'electronRebuild'...
Running: yarn run electron-rebuild --force-abi 89
[12:18:51] Finished 'electronRebuild' after 1.87 s
• electron-builder version=22.14.10 os=21.4.0
• loaded configuration file=package.json ("build" field)
• electron-rebuild not required if you use electron-builder, please consider to remove excess dependency from devDependencies
To ensure your native dependencies are always matched electron version, simply add script `"postinstall": "electron-builder install-app-deps" to your `package.json`
• writing effective config file=dist/builder-effective-config.yaml
• skipped dependencies rebuild reason=npmRebuild is set to false
• packaging platform=darwin arch=arm64 electron=14.1.0 appOutDir=dist/mac-arm64
• signing file=dist/mac-arm64/Joplin.app identityName=Apple Development: myemail@gmail.com (HTMU9ABGMT) identityHash=C1D714D9D*E49520D66068BTDB52QD54C2C12T1B provisioningProfile=none
Checking if notarization should be done...
Either not running in CI or not processing a desktop app tag - skipping notarization. process.env.IS_CONTINUOUS_INTEGRATION = undefined; process.env.GIT_TAG_NAME = undefined
• building target=DMG arch=arm64 file=dist/Joplin-2.8.3-arm64.dmg
• Detected arm64 process, HFS+ is unavailable. Creating dmg with APFS - supports Mac OSX 10.12+
The process ended here and the Joplin.app is not working. I think the build process is not completed though it didn't give any errors.