due notes count when opening the app for first time each day

zeppo's Avatar


13 Jun, 2019 05:20 PM

Just curious, usually when I open the app, I have studied all the due notes from the previous day, so initially the "Due for Study" field on the home screen will be blank. Then, after a minute or two, it will be populated by a number. Usually this number doesn't change. The process of generating due notes is complete. But occasionally the field will be populated first with one number, and then a minute or so later, without touching or navigating the app, it is replaced by a larger number. I just find it odd that the app is apparently sometimes populating that field with a number before the process of determining all notes Due for Study is complete.

This happened again today.

I've seen this many times and wondered if there could be bug like an additional file being created and run to generating due notes when there should just be one file, and also that this could be contributing to sync issues. Or a function to generate dues notes is somehow aborted causing the first number to appear, and then is resumed to generate the final number, but also causing a problem with long sync times as the app tries to sync after the first aborted attempt at the same time as the the function is resumed and generating new due notes, and then a second sync attempt is attempted while the first is still going on, etc etc.

Anyway, I've wondered if this is the sign of a small problem that might be the indication of a the cause of much bigger ones.

  1. Support Staff 1 Posted by drewmccormack on 14 Jun, 2019 07:28 AM

    drewmccormack's Avatar

    I don't think it is a problem. The scheduling can occur in the background when the app gets woken, so it's possible it already has a number.


  2. drewmccormack closed this discussion on 14 Jun, 2019 07:28 AM.

  3. zeppo re-opened this discussion on 14 Jun, 2019 01:13 PM

  4. 2 Posted by zeppo on 14 Jun, 2019 01:13 PM

    zeppo's Avatar

    I don't have background refresh activated for the app.

    This was the first time the app had been opened that day (going back to the previous afternoon). and the Due for Study field was empty when the app was first opened. So it doesn't not appear that the app already had a number. About 30 seconds after opening the number 5 appears in the Due for Study field. Then about three minutes after that it is replaced with the number 79. It would appear that either scheduling was initiated and then aborted/disrupted, or there were two separate instances of scheduling going on, after which the Due for Study field was populated with the number five from the first attempt.

  5. drewmccormack closed this discussion on 17 Jun, 2019 08:53 AM.

  6. zeppo re-opened this discussion on 17 Jun, 2019 02:15 PM

  7. 3 Posted by zeppo on 17 Jun, 2019 02:15 PM

    zeppo's Avatar

    It also happened the following day in the same manner, but first showing 5 Due for Study. The one thing in common was they were from the same parent folder or "case" as you call them, but from different stacks in that folder. (That "case" is itself within another "case" of a group of cases). I don't know if this is because the process of searching for due notes always begins with the same "case", or if there is some reason this particular case has become a part of a second due notes process that is being run, and which perhaps is not always evident because of the smaller grouping of notes within it not always having anything due.

  8. 4 Posted by zeppo on 17 Jun, 2019 11:17 PM

    zeppo's Avatar

    I checked back on all the previous times I noted this problem and see that the cards initially scheduled notes do come from all different folders/cases. And while the first number of Due notes is usually small, there have been a couple of times where it was initially a rather large number (e.g., once it was 56 which changed to 84).

    Obviously there's no way I'll be able to figure out the cause, but I would consider what occurs per code once the Due for Study number posts-- if a sync is triggered, then this could be a problem where the app is trying to sync the first number which is shortly after changed and a second sync attempted while the first is still in progress, etc. Could this be the cause of a hanging sync attempt that is interminably long, the first attempt aborted by the second, but then the first (first number due) attempts to resync, aborting the second, etc etc. ? I mean, I have no idea how it works, I'm just imagining ways it could be a problem that is linked to the sync issues this app has.

    By the way, the "updating library" text in the pop up that used to appear seems to be gone since the last update. Pop up still occurs, but with just a blank white space now where the text used to be. Not sure if this was intentional.

  9. Support Staff 5 Posted by drewmccormack on 18 Jun, 2019 07:17 AM

    drewmccormack's Avatar

    To me it does sound like something that could arise due to sync, but I thought the sync was turned off now (?)


  10. 6 Posted by zeppo on 18 Jun, 2019 02:23 PM

    zeppo's Avatar

    I turned sync off in February because of the unsolvable problems, mainly, but also to see what issues occur with each app when they are the only app loaded and used. Unless this is a relic that persists from when I was syncing, it isn't caused by sync. It seems likely that it occurs just as a product of the coding, but what I am wondering is if it might be the _cause_ of sync issues (ie, long sync times and/or crashes) that I had when sync was active prior to February. If you were to look at whatever code would cause the Due for Study field to populate this way, and then see if that same code would trigger a sync, then it is possible that there are conflicts causes when the two apps simultaneously trying to sync both values, an initial sync of the first Due for Study value and a second sync of the second Due for Study value. If that were the case, then one way to clean up the issue is to find out what is causing the field to populate twice. Is something being aborted? Is some file/function triggered to be run twice when it should only run once? Are there two instances/files etc that have been created that are triggering this to happen twice when it should only happen once? Then it would seem to me cleaning that up would help.

  11. drewmccormack closed this discussion on 19 Jun, 2019 06:08 AM.

  12. zeppo re-opened this discussion on 15 Jul, 2019 02:54 AM

  13. 7 Posted by zeppo on 15 Jul, 2019 02:54 AM

    zeppo's Avatar

    I believe it may be that taking a screenshot when I first open the app for the day, before it has scheduled (none showing due) may be what sometimes causes the due notes field to populate with a smaller number before settling on the larger final number. I stopped taking screenshots during this time and so far it has stopped doing this.

  14. drewmccormack closed this discussion on 16 Jul, 2019 03:13 AM.

  15. zeppo re-opened this discussion on 19 Jul, 2019 02:36 PM

  16. 8 Posted by zeppo on 19 Jul, 2019 02:36 PM

    zeppo's Avatar

    Spoke too soon. I stopped taking screenshots when opening, but on Wednesday when I turned on long-term scheduling for a stack (that had been loaded many days before) the issue returned yesterday morning when I opened the app for the first time that day. The length of time to complete the scheduling with the final number due also doubled from around 2 minutes to four. Happened again today, including lengthier scheduling time. So screenshots not involved.

  17. drewmccormack closed this discussion on 20 Jul, 2019 11:33 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac