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.

Showing page 2 out of 2. View the first page

  1. 31 Posted by zeppo on 25 Feb, 2020 03:49 PM

    zeppo's Avatar

    PS: My notes are strictly text-- no images or audio.

  2. Support Staff 32 Posted by Vlad Borovtsov on 26 Feb, 2020 05:23 AM

    Vlad Borovtsov's Avatar

    Well, actually images or audio doesnt add any complexity in this case. The key thing is that you have a lot. I'll look what i can do, maybe there is a way to make logic run smoothly.

  3. Vlad Borovtsov closed this discussion on 26 Feb, 2020 05:23 AM.

  4. zeppo re-opened this discussion on 26 Feb, 2020 04:45 PM

  5. 33 Posted by zeppo on 26 Feb, 2020 04:45 PM

    zeppo's Avatar

    Thanks. If you have any questions let me know. When you look into the unexpected cause of these displayed "counts" (perhaps because an assumption was made that was too small about how large a library would be or how many would come due in a day?), you might see if for a similar reason this is triggering multiple requests to sync and perhaps even queuing them all so that where most people get one group of data that needs to be synced, I'm having to have multiple updates synced, or some kind of log jam is occuring that is causing start and stops of syncs, or multiple sets of data needing to be resolved, etc etc. I'm sure it is probably not intended that this would happen with sync, but it also seems to me that this count up was not intended-- so even though it might not be expected, worth taking a closer look at whatever unintended consequences my library is triggering.

  6. 34 Posted by zeppo on 26 Feb, 2020 04:45 PM

    zeppo's Avatar

    ps : for what it is worth, here is today's:

    clicked to open app (11:17:50)
    appears onscreen at 11:17:52
    39 seconds later (11:18:31 ) due count shows at 76
    10 seconds later count is 134 (11:18:41)
    9 seconds later (11:18:50) count is 205, flickers back to 134, then up to 228 (10:18:51), then back to 134, then 228, (10:18:52), which is the final number due

  7. Support Staff 35 Posted by Vlad Borovtsov on 26 Feb, 2020 04:48 PM

    Vlad Borovtsov's Avatar


    it seems i accidentally caught your counting issue today.

  8. 36 Posted by zeppo on 26 Feb, 2020 05:44 PM

    zeppo's Avatar

    Using my database?

  9. Support Staff 37 Posted by Vlad Borovtsov on 26 Feb, 2020 05:48 PM

    Vlad Borovtsov's Avatar

    No, that counting is happening with any huge DB. My current testing one contains about 20k notes.

  10. 38 Posted by zeppo on 10 Mar, 2020 06:00 PM

    zeppo's Avatar

    Hi, Vlad   
    Just curious if you've looked at the code and learned anything more about this.
        On Wednesday, February 26, 2020, 12:48:08 PM EST, Vlad Borovtsov <[email blocked]> wrote:

  11. Support Staff 39 Posted by Vlad Borovtsov on 10 Mar, 2020 06:06 PM

    Vlad Borovtsov's Avatar


    yes, i think i've found it.
    But the problem is that i didn't come to solution i like.

    The most obvious fix solves the counting problem, but then counts starts flickering during updates. Due to complex app architecture, nice solution will take time :)

  12. 40 Posted by zeppo on 10 Mar, 2020 08:25 PM

    zeppo's Avatar

    Why does it sometimes flash back to a lower count more than once?

    And when the program requests a count to display is it at the same time also triggering some instructions that will affect how long sync will take, or, for instance, multiple saved states that each one of which now need to be merged and/or synced? I don't know how it works. I'm just wondering since this is an unintended event that happens with larger libraries, if maybe there are other unintended events triggered at the same time that explain why my sync times grow to be so ridiculously long (like triggering syncs that are interrupted, or multiple states that are requested to be synced instead of just one.)

  13. Support Staff 41 Posted by Vlad Borovtsov on 11 Mar, 2020 06:01 AM

    Vlad Borovtsov's Avatar

    It flashes back to a lower count bcs of cache.
    If i remove the cache, it will start showing a correct value, but there will be short moments when count is just missing.

    this is happening bcs stacks list and "due notes update" routine running in a separate contexts for better performance. Stacks list notices a change in DB and trying to reload, but counting of exact count due notes is kind of heavy operation, to it gets placed into queue, while stack list takes cached value immediately, just to keep displaying something.

    As for the sync, of course, due states update doing some modification in DB and will trigger sync. But solving that counting UI issue won't affect sync performance at all.

  14. 42 Posted by zeppo on 11 Mar, 2020 01:59 PM

    zeppo's Avatar

    Yeah, my thought wasn't that solving the *display* of "count up" would *solve* some sync issue as well, but, rather, would *alert* you to some *corresponding* sync issue that would have to be solved independently. For instance, if an unintended command to display the count is taking place the where the assumption in the code was this would be taking place at the *end* the completion of calculation of total due notes. In that scenerio, I wondered if maybe such an unintended command to display was also accompanied by another order to save a state that would then be requested to be synced (again with operating under the false assumption that final determination of due notes was complete, when in fact it was not yet complete). In that case, just as there were multiple commands to display the due notes counts where only one was intended to be displayed at the end, there might also be multiple commands regarding sync where only one was intended at the end -- so that you have interrupted start and stops of requests to sync, or you have much larger amount of information requested to be synced (multiple states with increasingly updated information) rather than just a single state with the final due count at the end of the process. Again, I am thinking of possibilities without knowing the code, just possible logic that I could imagine happening in a program.

    At the end, even if this were true, one could say that this is not important if you don't care about time and how much data is synced. But for me it sync time has always been a big problem (30 minutes to over an hour), and is sometimes accompanied by more than just a couple of "sync progress" bars that have made me wonder in the past just how many times the app is trying to sync, or if the sync is stopping and starting again, etc.

    Again, obviously this would be much less of a blind process for me if I knew the structure and the code, so I apologize for that, but as it stands, I'm curious if something some *corresponding* (not direct) connection to sync might be going on here. I figure if the odds are against it its still a stone worth turning over given these sync times. Anyway, I appreciate that you are taking a look at this, Vlad. Thanks.

  15. Support Staff 43 Posted by Vlad Borovtsov on 11 Mar, 2020 05:38 PM

    Vlad Borovtsov's Avatar

    Yeah, i'll check it. Honestly, there are a lot of sync triggers to make UX seamless as much as possible between the desktop and mobile version.

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

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