yup
Hmm. Did you force close Joplin from the app info screen immediately beforehand?
My note saved as an untitled empty note when I tested this way, by the way.
All of my tests were from a freshly rebooted phone so neither Joplin nor Firefox should have been running before I pressed the buttons
I'm still constantly having problems with this. Does anyone have any ideas what it could be?
Often, items won't save unless I make edit first after sharing. Once in a while, an empty note is saved instead.
Do you see any errors in log? What app are you sharing from and what sort of content?
I'll try to reproduce it in the emulator.
I'm almost always sharing Firefox web pages to Joplin using its built in share function. It simply shares a URL.
I just checked the log. Let me describe what I'm seeing. First, a timeline of what I'm doing:
Time 1: Open Firefox and share a link to Joplin. Immediately exit the Joplin note that appears by using the Android Back gesture.
Time 2 (a few seconds later): Go to home screen and start Joplin. Go to settings, open log.
In the log I'm seeing some activity, but the following is notable from each timeframe above.
Time 1: Starting application net.cozic.joplin-mobile (prod)
(The app was not running. This sharing / note saving issue doesn't seem to happen if the app is running. There are no errors at Time 1.)
Time 2: ResourceService::indexNoteResources: A change was recorded for a note that has been deleted:asdfisadfui4543254
(I didn't type that last string exactly; I figure it's not important. I am note sure what this error means, but I did not delete or change any notes since the last sync.
No errors except for this one, and nothing else of importance that I can see.
Hope that's useful. Thanks for looking into this.
Thanks it is useful.
I could not reproduce it yesterday though I shared files, not URLs or text.
(Found another issue though but again only for attachments.)
I have also tried to repeat the other similar issue where notes created from quick actions aren't saved. Again, no luck, all works as expected for me on Android 11 running in emulator.
I have also tried to repeat the other similar issue where notes created from quick actions aren't saved.
The one discussed here doesn't imply they aren't saved. The New Note actions from the Joplin home screen icon simply doesn't take one to a new note. However, the triggering condition is reversed: that only occurs if Joplin already is loaded in Android as an in-memory recent app.
Nope, still can't reproduce, sorry.
One question on this
do you really exit immediately or wait for the text to appear first? I suppose if you are very fast you could exit before the note is fully loaded and this can cause the note to be discarded.
I do wait for the text.
I have found one issue with sharing files: Mobile: Fix incorrect field name when attaching a resource from share by roman-r-m · Pull Request #4557 · laurent22/joplin · GitHub
(Which I have introduced myself when trying to fix attaching files)
However, I do not think it's related to what you're describing.
The only other suggestion I have is I can build a custom APK for you with extra logging that might be able to shed some light on what's going on, if you're willing to install a file from a stranger on the internet. Of course, you don't need to use it with your actual notes - as long as you can reproduce the problem.
Thanks for the offer. I can consider doing this, won't be able to for a little while (need to prep a different phone). @timf also had this issue. I wonder if he can test?
@roman_r_m
Also, have you seen this issue?
That one also is an issue that is affected by whether Joplin is in memory, though it's the other way around: functionality is broken if app is in memory, and works well if it is not. I and @Daeraxa can reproduce. Can you?
I mention it because I wonder if some process is acting differently based on whether Joplin has just loaded or was already in memory, and perhaps that will lead to the root cause of both the problem described here, and the one I linked to above. Perhaps looking at that will be a simpler way to locate the issue.
I have seen it, but could not reproduce, neither on my Android 9 phone, nor on Android 11 in emulator.
I'm pretty sure it's the same root cause btw.
Ok, thanks. I'm on Android 10, not 11 by the way.
@roman_r_m
Why are you not seeing this yourself or in an emulator? Why are only some people reporting this? Does the Android version really matter? I have a theory.
When you did your emulator testing, did you have sync configured? Based on some timings, and my observations, I suspect that "having Joplin not in memory" being a trigger for this issue may really be down to some process that occurs with sync when Joplin opens. I have many notes, and when I first open Joplin I have to wait about 5 to 10 seconds for the app to become responsive. I believe this is while sync is going through some initial stages, since at the time I can see on the main screen that sync has started but is showing no "fetching" yet. I can't do much in the app until this initial stage is done. This doesn't happen on subsequent syncs if Joplin is already in memory. I can be navigating around notebooks and notes, and sync happens in the background without me noticing. No lags of any sort.
Perhaps something in sync is taking a while during this initial stage and the app is not "ready" for note creation if I share to it from another app. That would explain why some others don't see this. Perhaps they don't have auto sync configured. Perhaps they don't have as many notes. Perhaps they have fewer apps running or more memory, and Joplin stays in memory more often.
I have 10,000 note items and 50,000 resource items, and I use Dropbox sync. Perhaps @timf can also let us know if he has a lot of notes and sees the same type of lag with sync on each app open.
This is a very good point, I didn't think of it. I will try to test it in the next few days.
This sounds similar to my configuration- a webdav sync to a local nginx instance on my home network.
Joplin typically takes about 5 seconds to start after I've done a "force stop"
If its more responsive for you, I bet it'll be hard to reproduce this bug.
Maybe this excerpt of the debug report could help with showing the timing here?
Date,Level,Message
02-24T19:36:35,30,"""SearchEngine: Updated FTS table in 11ms. Inserted: 0. Deleted: 0""
02-24T19:36:35,30,"""SearchEngine: Updating FTS table...""
02-24T19:36:29,30,"""DecryptionWorker: cannot start because no master key is currently loaded.""
02-24T19:36:29,30,"""RevisionService::maintenance: Done in 138ms""
02-24T19:36:29,30,"""RevisionService::collectRevisions: Created revisions for 0 notes""
02-24T19:36:29,30,"""RevisionService::maintenance: Service is enabled""
02-24T19:36:29,30,"""RevisionService::maintenance: Starting...""
02-24T19:36:28,30,"""Garbage collecting alarms...""
02-24T19:36:28,30,"""Updating all notifications...""
02-24T19:36:28,30,"""Total notes: 430""
02-24T19:36:28,30,"""Total resources: 112""
02-24T19:36:28,30,"""Total folders: 4""
02-24T19:36:28,30,"""fetchingTotal: -""
02-24T19:36:28,30,"""Operations completed: ""
02-24T19:36:27,30,"""BasicDelta: Report: {"timestamp":1613865659000,"older":1307,"newer":0,"equal":2}""
02-24T19:36:26,30,"""Sync target info:", "{"version":2}""
02-24T19:36:26,30,"""Starting scheduled sync""
02-24T19:36:26,30,"""Preparing scheduled sync""
02-24T19:36:26,30,"""DecryptionWorker: cannot start because no master key is currently loaded.""
02-24T19:36:25,30,"""ResourceFetcher: Auto-added resources: 0""
02-24T19:36:25,30,"""RevisionService::runInBackground: Starting background service with revision collection interval 30000""
02-24T19:36:25,30,"""Application initialized""
02-24T19:36:25,30,"""ResourceFetcher: Auto-add resources: Mode: auto""
02-24T19:36:25,30,"""Loading folders...""
02-24T19:36:25,30,"""Loaded master keys: 0""
02-24T19:36:25,30,"""Trying to load 0 master keys...""
02-24T19:36:25,30,"""Sync target: 6""
02-24T19:36:25,30,"""PluginAssetsLoader: Assets are up to date. Hash: b95f9e5e2fcd1715be753f1c96235272""
02-24T19:36:25,30,"""KeychainService: check was already done - skipping. Supported:", "0""
02-24T19:36:25,30,"""KeychainService: checking if keychain supported""
02-24T19:36:24,30,"""Loading settings...""
02-24T19:36:24,30,"""Database is ready.""
02-24T19:36:24,30,"""New version: 34. Previously recorded version: 34""
02-24T19:36:24,30,"""Upgrading database from version 34""
02-24T19:36:24,30,"""Current database version", "{"table_fields_version":34,"version":34}""
02-24T19:36:24,30,"""Checking for database schema update...""
02-24T19:36:24,30,"""Database was open successfully""
02-24T19:36:24,30,"""Starting application net.cozic.joplin-mobile (prod)""
02-24T19:36:24,30,"""====================================""
I see you have 430 notes. I have over 20 times as many on my phone. Before using Dropbox, my first experience with Joplin Android was using local file sync. The startup lag was over 20 seconds if I recall correctly. It was completely unusable. I read somewhere on this forum that Webdav was also slow for those with many notes.
Just FYI, in case it's helpful.
@roman_r_m :
As for this bug, I suspect the easiest way to reproduce similar conditions would be to create a test instance with several thousand notes, and sync via Webdav or local file sync. If you can get a 10 or so second startup lag, I bet the local share function will fail reliably.
Here's my log, for reference. Note that UI lag / lack of responsiveness lasted for about 5 seconds after launch in this case. Perhaps adding a note depends on something before the step labeled "Application Initialized", which is about 4 seconds into the process.
When I just tried (and failed to save) a note to Joplin through sharing, the shared note opens approximately 6 or 7 seconds after a blank Joplin app opens. seconds go by. I looked at the log again, and there were some differences from the below. However, the most notable ones were these details that appeared in the log from the failed attempt to share:
Provisional service was not modified - deleting it
AND
SearchEngine: Updated FTS table in 519ms. Inserted: 0. Deleted: 1
I hadn't deleted anything in between these tests, so I'm wondering if this deletion was somehow indicating that some sort of cached addition of my shared note was backed out. Full log referenced above follows....
02-24T15:56:32,30,"""DecryptionWorker: completed decryption.""
02-24T15:56:32,30,"""DecryptionWorker: starting decryption...""
02-24T15:56:31,30,"""Garbage collecting alarms...""
02-24T15:56:31,30,"""Updating all notifications...""
02-24T15:56:31,30,"""Total resources: 52560""
02-24T15:56:31,30,"""Total folders: 9""
02-24T15:56:31,30,"""Total notes: 10092""
02-24T15:56:31,30,"""fetchingTotal: -""
02-24T15:56:31,30,"""Operations completed: ""
02-24T15:56:26,30,"""SearchEngine: Updated FTS table in 59ms. Inserted: 0. Deleted: 0""
02-24T15:56:26,30,"""SearchEngine: Updating FTS table...""
02-24T15:56:20,30,"""RevisionService::maintenance: Done in 156ms""
02-24T15:56:20,30,"""RevisionService::collectRevisions: Created revisions for 0 notes""
02-24T15:56:20,30,"""RevisionService::maintenance: Starting...""
02-24T15:56:20,30,"""RevisionService::maintenance: Service is enabled""
02-24T15:56:19,30,"""Sync target info:", "{"version":2}""
02-24T15:56:17,30,"""Starting scheduled sync""
02-24T15:56:17,30,"""Saving updated Dropbox auth.""
02-24T15:56:17,30,"""Preparing scheduled sync""
02-24T15:56:17,30,"""DecryptionWorker: completed decryption.""
02-24T15:56:16,30,"""ResourceFetcher: Auto-added resources: 0""
02-24T15:56:16,30,"""Application initialized""
02-24T15:56:16,30,"""RevisionService::runInBackground: Starting background service with revision collection interval 30000""
02-24T15:56:16,30,"""ResourceFetcher: Auto-add resources: Mode: always""
02-24T15:56:14,30,"""DecryptionWorker: starting decryption...""
02-24T15:56:13,30,"""Loading folders...""
02-24T15:56:13,30,"""Trying to load 1 master keys...""
02-24T15:56:13,30,"""Loaded master keys: 1""
02-24T15:56:13,30,"""Sync target: 7""
02-24T15:56:13,30,"""PluginAssetsLoader: Assets are up to date. Hash: b95f9e5e2fcd1715be753f1c96235272""
02-24T15:56:13,30,"""KeychainService: checking if keychain supported""
02-24T15:56:13,30,"""KeychainService: check was already done - skipping. Supported:", "0""
02-24T15:56:13,30,"""Database is ready.""
02-24T15:56:13,30,"""Loading settings...""
02-24T15:56:13,30,"""New version: 34. Previously recorded version: 34""
02-24T15:56:13,30,"""Upgrading database from version 34""
02-24T15:56:13,30,"""Current database version", "{"table_fields_version":34,"version":34}""
02-24T15:56:13,30,"""Checking for database schema update...""
02-24T15:56:13,30,"""Database was open successfully""
02-24T15:56:13,30,"""Starting application net.cozic.joplin-mobile (prod)""
02-24T15:56:13,30,"""====================================""