tag:mentalfaculty.tenderapp.com,2010-10-19:/discussions/suggestions/10630-due-notes-count-when-opening-the-app-for-first-time-each-dayThe Mental Faculty: Discussion 2020-05-12T16:16:00Ztag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032019-06-13T17:20:00Z2019-06-13T17:20:00Zdue notes count when opening the app for first time each day<div><p>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.</p>
<p>This happened again today.</p>
<p>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.</p>
<p>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.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032019-06-14T07:28:11Z2019-06-14T07:28:11Zdue notes count when opening the app for first time each day<div><p>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.</p>
<p>Drew</p></div>drewmccormacktag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032019-06-14T13:13:12Z2019-06-14T13:13:12Zdue notes count when opening the app for first time each day<div><p>I don't have background refresh activated for the app.</p>
<p>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.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032019-06-17T14:15:09Z2019-06-17T14:15:09Zdue notes count when opening the app for first time each day<div><p>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.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032019-06-17T23:17:21Z2019-06-17T23:17:21Zdue notes count when opening the app for first time each day<div><p>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).</p>
<p>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.</p>
<p>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.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032019-06-18T07:17:06Z2019-06-18T07:17:06Zdue notes count when opening the app for first time each day<div><p>To me it does sound like something that could arise due to sync, but I thought the sync was turned off now (?)</p>
<p>Drew</p></div>drewmccormacktag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032019-06-18T14:23:16Z2019-06-18T14:23:16Zdue notes count when opening the app for first time each day<div><p>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 <em>cause</em> 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.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032019-07-15T02:54:23Z2019-07-15T02:54:23Zdue notes count when opening the app for first time each day<div><p>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.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032019-07-19T14:36:28Z2019-07-19T14:36:28Zdue notes count when opening the app for first time each day<div><p>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.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-20T18:26:20Z2020-01-20T18:26:20Zdue notes count when opening the app for first time each day<div><p>By the way, having moved my data to the mac app, I can confirm this behavior occurs on the mac app, too (as with today, with no data in the cloud, sync off (and both apps having used the Reset feature), and the iOS app installed on a factory reset phone but not yet synced (sync off).</p>
<p>For instance, opening the app for the first time today, starting with no due notes, after fourty-five seconds, the number 30 appeared in Due for Study. After ten more seconds it changed to 66. After another ten seconds, it changed to 83. After twenty-five more it changed to 86. After thirty more seconds, it changed to 94. I gave it another minute but it remained at 94, which was hopefully enough time for it to be the final number. It would be helpful if there was some pop up or other indicator that would let me know the scheduling task is complete so I don't interrupt it.</p>
<p>Have you ever noticed this "count up" behavior in due notes being scheduled, or does the final number due when scheduling a new batch each day always appear at once, (without a series of numbers appearing as it counts up to the final amount?)</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-20T18:32:44Z2020-01-20T18:32:44Zdue notes count when opening the app for first time each day<div><p>No, that sounds really odd. Scheduling should generally only take 10 seconds or so at the most.</p>
<p>Maybe the issue is that you have a lot of scheduling history. If you want, we can do some profiling with your data to see if we can make it faster. If you want to do this, zip up your mac library in Containers > com.mentalfaculty.studies.mac and share it with me.</p>
<p>Kind regards,<br>
Drew</p></div>drewmccormacktag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-20T18:38:35Z2020-01-20T18:38:35Zdue notes count when opening the app for first time each day<div><p>I'll get it over to you at some point. I have always wondered if whatever is causing this also manifests in my extremely long sync times (as in possibly essentially running mulitiple syncs corresponding to the multiple scheduling events, or syncs being triggered by one scheduling event (ie, in this case the first being 30 notes) but being interrupted by the next ("unexpected" ) scheduling event (in this case being 66) etc. I mean, obviously it could also affect in some other way I haven't thought of, but this has always been a behavior that I have seen.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-20T20:53:00Z2020-01-20T20:53:00Zdue notes count when opening the app for first time each day<div><p>I'm having trouble uploading to dropbox, getting an error on some files, even when I zip the library using the mac compression feature. Switching from Safari to Google. Seems to make a difference, but is taking a while to upload.</p>
<p>is <a href="mailto:drewmccormack@mac.com">drewmccormack@mac.com</a> the email address to use?</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-20T21:40:03Z2020-01-20T21:40:03Zdue notes count when opening the app for first time each day<div><p>I believe I have the mac app library zip file emailed to you or available for you on dropbox.</p>
<p>But I may follow up with another one later that is after studying all due notes today, so that if you happen to test it tomorrow you may see the same scheduling I see.</p>
<p>Zeppo</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-21T00:18:59Z2020-01-21T00:18:59Zdue notes count when opening the app for first time each day<div><p>I had a few confusing and botched attempts to get the more recent file to you that is from after studying all due notes from today. But I believe it is on dropbox for you now in slightly compressed form. So when you open on Jan 21 it should schedule the same number for you as it does for me. The only question is whether it will exhibit this odd behavior. It usually does it more often than not.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-21T12:11:51Z2020-01-21T12:11:51Zdue notes count when opening the app for first time each day<div><p>We did a test of scheduling. On our admittedly powerful Macs, it took about 15 seconds. That's probably to be expected for a large library, because it has to effectively load and process every single note schedule.</p>
<p>What we did notice is that you have a few smart stacks. Smart stacks can slow things down quite a lot, because they are effectively searches, and whenever something changes, they have to be reprocessed. You might find the app gets quite a bit more snappy if you remove those.</p>
<p>Kind regards,<br>
Drew</p></div>drewmccormacktag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-21T14:42:54Z2020-01-21T14:56:03Zdue notes count when opening the app for first time each day<div><p>I don't mind the amount of time it takes to schedule, though I can eliminate some smart stacks. It is the amount of time it takes to sync that is a problem for me. So I was wondering if you see a "count up" to the final due notes number, or does the final number just pop in without any other numbers appearing before it? Not an actual count up of 1,2,3,4..., etc , but of a few interim numbers, today's being 33, 52, 79, then the final count of 80, in my case about 35 seconds apart, but with your perhaps a couple of seconds.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-21T16:16:55Z2020-01-21T16:16:55Zdue notes count when opening the app for first time each day<div><p>PS: Actually I was thinking I had more smart stacks than I do. I have used others in the past but must have deleted them at some point. The two I do have now I just created in the past couple of days and have had no bearing on the apps behavior that I have described. Nothing has changed in how the app behaves for me. Maybe they will add to the time needed to sync, but I haven't turned that on yet since creating these smart stacks. I only need the smart stack in order to sort and tag certain cards that, though graded wrong on last study, were nevertheless given a next due date of over a year because of the bug in your app that you've finally corrected. Now that I have moved the data to the mac app, I want to sort and restudy these notes to correct their study scheduling. Then I can delete the smart stack.</p>
<p>But let me know if you see the "count up" behavior in my stack, and in your own test stacks that have a large number of cards like mine.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-21T17:23:41Z2020-01-21T17:23:41Zdue notes count when opening the app for first time each day<div><p>We did another test with your library and we can see the issue, it is counting, exactly as you described it. We will look more into the issue to see if its possible to get a better performance with heavy smart stacks.</p></div>Vlad Borovtsovtag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-21T17:32:53Z2020-01-21T17:51:15Zdue notes count when opening the app for first time each day<div><p>Thanks.</p>
<p>To be clear though, this "counting" behavior or any of the problems I've been having has nothing to do with smart stacks (unless there remains some unseen relics of every smart stack a user has created in the past even after deleting them.) The two I have were only recently created.</p>
<p>EDIT : "... has <em>nothing</em> to do with..."</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-22T07:13:58Z2020-01-22T07:13:58Zdue notes count when opening the app for first time each day<div><p>OK, that is more clear then. Vlad is investigating more now.</p></div>drewmccormacktag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-23T19:18:23Z2020-01-23T19:18:23Zdue notes count when opening the app for first time each day<div><p>drew and vlad:</p>
<p>using the library I sent you, sort All Notes for "medias"</p>
<p>You will see a card with first facet "medias de red"</p>
<p>Click on card and click on info.</p>
<p>You will see<br>
Last Studied: August 22, 2018 Next Scheduled: April 6 2020 Recent Run: 1 incorrect year and month retentions both 50%</p>
<p>Now turn off facet 2 as a prompt and click done.<br>
Click on card and click on info.</p>
<p>You will now see<br>
Last Studied: August 22, 2018 Next Scheduled: April 6 2020 Recent Run: 1 incorrect year and month retentions both 90%</p>
<p>Now turn back on facet 2 as a prompt.<br>
Turn off facet 1 as a prompt and click done.</p>
<p>Click on card and click on info.</p>
<p>You will now see<br>
Last Studied: August 22, 2018 Next Scheduled: August 23, 2018 Recent Run: 1 incorrect year and month retentions both 0%</p>
<p>Now turn back on facet 1 as a prompt and click done.</p>
<p>Click on card and click on info.<br>
Last Studied: August 22, 2018 Next Scheduled: August 23, 2018 Recent Run: 1 incorrect year and month retentions both 50%</p>
<p>This note is an example of what I'm trying to clean up now among my notes. It was caused by a bug I pointed out to you that you have since corrected. ( <a href="https://mentalfaculty.tenderapp.com/discussions/suggestions/10614-gradingscheduling-bug">https://mentalfaculty.tenderapp.com/discussions/suggestions/10614-g...</a> )<br>
But the problem is that when it comes to notes where both facets can be a prompt, I cannot simple sort to find these notes by due date. They like hidden easter eggs I can only find by using the steps I just gave you. That is why I created the "ALL" smart stack so that I can view and sort notes without being sorted by stacks as the All Notes.</p>
<p>Now sort All Notes for "lejos".<br>
You will see a card with first facet "lejos (adv)"</p>
<p>Click on card and click on info.</p>
<p>You will see<br>
Last Studied: July 5, 2019 Next Scheduled: September 10, 2029 Recent Run: 1 Correct Year Retention 0% Month Retention 20%</p>
<p>I'm going to have to sort out cards like this one that are being scheduled for over a decade out, despite the fact that my one month retention expectation is 20%. That's why I'm asking about parameters, as I figure out what I'm up against in terms of where this app is falling short and my strategies to correct it.</p>
<p>I'm also pointing this out because maybe there is something here that is involved with my data that is involved with the sync issues I have had. I'll also point out that I have notes going back to 2012 with the original Mental Case 1, so maybe there is something in they way notes were migrated into Mental Case 2 and Studies along the way that are involved. I'm only just starting to take on the task of "catching up" on notes like these. That's why I've switched over to the mac app for now (I don't use sync between mac app and iOS app because I've given up on that, except in this case where I had to move data over to mac.)</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-01-24T07:21:25Z2020-01-24T07:21:25Zdue notes count when opening the app for first time each day<div><p>We'll see if we can look into this at some point. Busy with disappearing images at the moment.</p></div>drewmccormacktag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-23T18:12:24Z2020-02-23T18:12:24Zdue notes count when opening the app for first time each day<div><p>I don't know if you solved the disappearing images problem in the last update and have had the chance to look at this yet. But its particularly interesting to me how in the "count up", the last update in the count, and sometimes the last two, will after increasing the displayed count for a split second flicker back to the previous count that was displayed . One day this week it was at its most peculiar:</p>
<p>8:26:58 am clicked to open the mac app --<br>
8:27:00 app displays on onscreen<br>
8:27:40 -- 40 seconds later 29 notes show due<br>
8:27:49 -- 9 seconds later 74 due<br>
8:27:59 -- 10 seconds 99 show due, the immediately flicker back to show 74 again...<br>
8:28:00 -- ... but returns 1 sec later with 117 due ( not 99 ), and flickers back again not to 99, but to 74 again<br>
8:28:01 -- shows 117 again, which remains the final count due</p>
<p>I don't have sync activated and should have all cloud data removed from resets, and internet not connected when I open app.</p>
<p>Seems odd to me, like there are multiple scheduling events being resolved.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-24T02:01:54Z2020-02-24T02:01:54Zdue notes count when opening the app for first time each day<div><p>Is this counting thing happening all the time?</p></div>Vlad Borovtsovtag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-24T09:15:55Z2020-02-24T09:15:55Zdue notes count when opening the app for first time each day<div><p>It is not necessarily unexpected that you would see the count update over time for a large library. The scheduling is done per stack, because it can take a little while. So as new stacks get scheduled, you may see the count rise, and eventually settle. This is as designed.</p>
<p>It is a bit odd that the number goes down, but that may just be due to some caching artefact in memory.</p></div>drewmccormacktag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-24T16:24:33Z2020-02-24T16:24:33Zdue notes count when opening the app for first time each day<div><p>Yes, Vlad, every time.</p>
<p>Today:<br>
clicked to open app , appears onscreen at 10:36:52<br>
45 (10:37:37 ) seconds due count shows at 71<br>
10 seconds later count is 121<br>
7 seconds later count is 146, flickers back to 121, then to 146 (10:37:52)<br>
27 seconds later (10:38:19) count changes to 178 ,flickers back 1 sec to 146, then up to 192, flickers back to 146, then back to 192 (10:38:21 ) which is the final number due</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-24T16:27:49Z2020-02-24T16:27:49Zdue notes count when opening the app for first time each day<div><p>Seems odd that a cache would hold on to 146, but not 178.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-24T17:10:50Z2020-02-24T17:10:50Zdue notes count when opening the app for first time each day<div><p>Actually, now that I think of it, Vlad, it hasn't always done it every time. There was a stretch where sometimes it would do it and sometimes it wouldn't. Maybe perhaps a factor of how many end up being due, I don't know. I've added activated long term scheduling for some more notes recently, so I'm back to getting due note counts over 100 more regularly.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-25T04:19:43Z2020-02-25T04:19:43Zdue notes count when opening the app for first time each day<div><p>Hm, ok.<br>
Do you have a lot of notes in DB? Does it takes long for Studies to process all due?</p></div>Vlad Borovtsovtag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-25T15:48:53Z2020-02-25T15:48:53Zdue notes count when opening the app for first time each day<div><p>If you look back in this thread to Jan 21, you will recall that I actually sent you my database and you saw the same "counting up" behavior. But you had to put it aside to work on the image deletion problem. I have about 9500 notes with long-term scheduling. It typically takes about a minute and a half. I included time stamps for a couple of days in my last few posts. Here is today's:</p>
<p>clicked to open app 10:20:59 , appears onscreen at 10:21:01<br>
44 (10:21:45 ) seconds due count shows at 50<br>
10 seconds later count is 123<br>
17 seconds later (10:22:12 ) count is 155<br>
20 seconds later (10:22:29) count changes to 163 ,flickers back 1 sec to 155, then up to 186 (10:22:31), which is the final number due</p>
<p>The flickering back and forth of the due count is fast and sometimes tricky to catch. I was manually advancing the frames of video I took. As of today, I started using slow motion to make it easier. The initial 40-45 seconds, followed by a 9-10 second gap to the next "count up" seems to be consistent. After that its more random as to when the due count changes.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-25T15:49:52Z2020-02-25T15:49:52Zdue notes count when opening the app for first time each day<div><p>PS: My notes are strictly text-- no images or audio.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-26T05:23:48Z2020-02-26T05:23:48Zdue notes count when opening the app for first time each day<div><p>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.</p></div>Vlad Borovtsovtag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-26T16:45:09Z2020-02-26T16:45:09Zdue notes count when opening the app for first time each day<div><p>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.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-26T16:45:36Z2020-02-26T16:45:36Zdue notes count when opening the app for first time each day<div><p>ps : for what it is worth, here is today's:</p>
<p>clicked to open app (11:17:50)<br>
appears onscreen at 11:17:52<br>
39 seconds later (11:18:31 ) due count shows at 76<br>
10 seconds later count is 134 (11:18:41)<br>
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</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-26T16:48:08Z2020-02-26T16:48:08Zdue notes count when opening the app for first time each day<div><p>Hi,</p>
<p>it seems i accidentally caught your counting issue today.</p></div>Vlad Borovtsovtag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-26T17:44:53Z2020-02-26T17:44:53Zdue notes count when opening the app for first time each day<div><p>Using my database?</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-02-26T17:48:01Z2020-02-26T17:48:01Zdue notes count when opening the app for first time each day<div><p>No, that counting is happening with any huge DB. My current testing one contains about 20k notes.</p></div>Vlad Borovtsovtag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-03-10T18:00:53Z2020-03-10T18:00:53Zdue notes count when opening the app for first time each day<div><p>Hi, Vlad <br>
Just curious if you've looked at the code and learned anything more about this.<br>
thanks<br>
On Wednesday, February 26, 2020, 12:48:08 PM EST, Vlad Borovtsov <a href="mailto:tender+d8064550f9@tenderapp.com">tender+d8064550f9@tenderapp.com</a> wrote:</p>
<table>
<tr>
<td></td>
</tr>
</table></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-03-10T18:06:11Z2020-03-10T18:06:11Zdue notes count when opening the app for first time each day<div><p>Hey,</p>
<p>yes, i think i've found it.<br>
But the problem is that i didn't come to solution i like.</p>
<p>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 :)</p></div>Vlad Borovtsovtag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-03-10T20:25:41Z2020-03-10T20:25:41Zdue notes count when opening the app for first time each day<div><p>Why does it sometimes flash back to a lower count more than once?</p>
<p>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.)</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-03-11T06:01:16Z2020-03-11T06:01:16Zdue notes count when opening the app for first time each day<div><p>It flashes back to a lower count bcs of cache.<br>
If i remove the cache, it will start showing a correct value, but there will be short moments when count is just missing.</p>
<p>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.</p>
<p>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.</p></div>Vlad Borovtsovtag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-03-11T13:59:16Z2020-03-11T13:59:16Zdue notes count when opening the app for first time each day<div><p>Yeah, my thought wasn't that solving the <em>display</em> of "count up" would <em>solve</em> some sync issue as well, but, rather, would <em>alert</em> you to some <em>corresponding</em> 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 <em>end</em> 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.</p>
<p>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.</p>
<p>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 <em>corresponding</em> (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.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-03-11T17:38:55Z2020-03-11T17:38:55Zdue notes count when opening the app for first time each day<div><p>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.</p></div>Vlad Borovtsovtag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-04-07T15:47:47Z2020-04-07T15:52:33Zdue notes count when opening the app for first time each day<div><p>Odd event regarding this happened Mar 28. For some reason the mac app took a much longer time than usual scheduling due notes:<br>
Mar 28 - LONG TIME SCHEDULING FOLLOWED LATER BY CRASH<br>
11:08:50 click to open<br>
11:08:54 app appears onscreen<br>
11:10:11 30 due<br>
11:11:34 68 due<br>
11:14:47 124 due<br>
11:15:45 68 due<br>
11:15:47 129 due<br>
11:15:47 68 due<br>
11:15:49 129 final due count</p>
<p>The normal amount of time it takes is about one and a half minutes. Pretty consistently it will show the first due count at about 45 seconds followed by the next count up about 10 seconds later. After those first two counts, it is more variable on when and how many more updates to the count appears. But as you see on Mar 28, the whole process took about seven minutes. Because it took so long, I didn't really trust that it was complete at 129 due and just left the app open. When I remembered and went back to it, it crashed around 11:21:00 A crash report was sent to Apple and I believe one was sent to you because of having previously selected to automatically send them to you. But I wasn't prompted with the chance to add any note, so I'm not sure. At any rate, I saved the report</p>
<p>I have just been using my iphone to take slow-mo video of the count and time, and was almost that very day going to quit doing it, figuring I pretty much had any useful data I was going to get from it, with the app pretty much having the same routine. For some reason I decided to do one more, and lo and behold, it turned out this odd event.</p>
<p>So you might check for my crash report.</p>
<p>But also, is there a way you could at least change the font of the final due number so I would have some indication of when the processing of the count is complete? Perhaps in bold like the "All Notes" count. Or maybe have all these intermediate due note counts in black and the final in blue. Or maybe the final due in red? (Different colors is easier to distinguish than bold vs regular) . It would help me avoid shutting down the app in the middle of the process, thinking it was complete when it wasn't. It would also let me know whether the app is trying to sync before the due notes count is complete. I don't have sync enabled, or even have my iphone app installed right now. But when I was using the iphone and tried to sync, this was always a concern in regards to the cause of the ridiculously long sync times. I would even try not having my phone connected to the internet when opening for the first time each day and wait until the scheduling was complete to connect. But in cases like this, after a couple of minutes, I am likely to assume the process is complete after a couple of minutes, when in reality it has 5 more minutes to go.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-04-08T06:32:29Z2020-04-08T06:32:29Zdue notes count when opening the app for first time each day<div><p>Hello,<br>
the scheduling usually should not take long, but its strongly depends on the size of your library. The study metadata is also lightweight, so it should not affect sync speed so much, but it also depends on size of your library and study rules assigned to stacks.</p>
<p>If you want us to investigate your particular case, can you share your library with us?<br>
As for background schedule indication - i'll think about it.</p></div>Vlad Borovtsovtag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-04-08T14:42:47Z2020-04-08T14:42:47Zdue notes count when opening the app for first time each day<div><p>If you can make a change so we know when scheduling is complete, then the use can relate some more info to you as to when in the process a problem is occuring.</p>
<p>You already have my library. As for that particular day where it went from a "normal" (for me) scheduling time of 1.5 minutes to 7 minutes, I don't have a saved copy of the library for that day. But you might glean something from the crash report that I believe was sent to you, or I can email it to you.</p>
<p>the summary was:<br>
Crashed Thread: 11 Dispatch queue: SQLQueue 0x7f94074124b0 for SyncedData.sqlite</p>
<p>Exception Type: EXC_CRASH (SIGABRT)<br>
Exception Codes: 0x0000000000000000, 0x0000000000000000<br>
Exception Note: EXC_CORPSE_NOTIFY</p>
<p>Application Specific Information:<br>
objc[756]: __NSArrayI object 0x60400058ad10 overreleased while already deallocating; break on objc_overrelease_during_dealloc_error to debug<br>
objc[756]: __NSArrayI object 0x6000003bd960 overreleased while already deallocating; break on objc_overrelease_during_dealloc_error to debug<br>
abort() called<br>
*** error for object 0x6040006a64e0: Invalid pointer dequeued from free list</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-04-08T14:50:45Z2020-04-08T14:50:45Zdue notes count when opening the app for first time each day<div><p>Hmm, yes, the that part of log says something. But such type of issues usually very hard to debug.</p>
<p>as for indication - i'll try to do something in the next release if possible.</p></div>Vlad Borovtsovtag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-04-08T15:05:35Z2020-04-08T15:05:35Zdue notes count when opening the app for first time each day<div><p>Thanks. Given that a fix to problems with lengthy scheduling and sync times may not be available to those of us with large and old libraries, it might at least help us to use the app in a way that reduces complications and also provide a little more useful info to you when problems occur.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-05-03T15:50:12Z2020-05-03T15:50:12Zdue notes count when opening the app for first time each day<div><p>Interesting that this count up behavior always happens on the mac app, but on the iphone app, sometimes it doesn't happen. I was reminded of this when I reinstalled the iphone app and switched back to using it. This is true with whether sync is turned on or not. I initially synced the data from the mac app to the iphone and used sync daily for a about a week, and sometimes it occurred and sometimes not. Since then I reset the cloud sync on both devices and haven't turned it back on, and still, sometimes the count up occurs and occasionally does not. This was true late last year when I was using the iphone app exclusively before switching to the mac app. So though the programming is supposed to be the same with both apps, there is this difference.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-05-03T16:50:33Z2020-05-03T16:50:33Zdue notes count when opening the app for first time each day<div><p>The code is exactly the same on each device. Most likely either you are seeing a case where sync has already done the scheduling, so it doesn’t happen again, or it just happens to go faster for some reason, with less refreshing.</p>
<p>Note that the iOS app can open in the background, so may do the scheduling before you open the app.</p>
<p>Kind regards,<br>
Drew</p></div>drewmccormacktag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-05-03T22:29:41Z2020-05-03T22:29:41Zdue notes count when opening the app for first time each day<div><p>I turned off sync, and I've always turned off background app refresh for the app.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-05-11T14:45:46Z2020-05-11T14:45:46Zdue notes count when opening the app for first time each day<div><p>What does the 33kb Data.sqlite-shm do?</p>
<p>When you open the iOS app for the first time on a given day, if this file updates, the "count up" issue does not occur. Otherwise, you get the "count up".</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-05-11T15:02:21Z2020-05-11T15:02:21Zdue notes count when opening the app for first time each day<div><p>It’s part of the database architecture. You shouldn’t mess with it. It is not specific to Studies, just to the database itself.</p>
<p>Drew</p></div>drewmccormacktag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-05-11T22:38:19Z2020-05-11T22:38:19Zdue notes count when opening the app for first time each day<div><p>Do you think sync attempts would be smoother when this file updates when the app opens for the first time of a given day-- that is, would the update of this file facilitate a less problematic sync? The fact that its update results in scheduling that doesn't have these odd "count ups" side effects makes me wonder if there are other side effects that might be avoided when it updates vs not updating.</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-05-12T07:05:45Z2020-05-12T07:05:45Zdue notes count when opening the app for first time each day<div><p>That file is simply used for any change to the database at all. It is not specific to scheduling, though it will change with scheduling because that is an update to the database. The race that causes the odd jumps is in the user interface layer, and is not related to the database.</p>
<p>Drew</p></div>drewmccormacktag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-05-12T15:48:19Z2020-05-12T15:48:19Zdue notes count when opening the app for first time each day<div><p>On the occasion where the "count up" occurs, the file doesn't change, even though the due notes number for the day has been generated (a process that typically takes about a minute fifteen seconds to two minutes. I would presume that during this time it is updating which notes are due for the day and would be considered scheduling.</p>
<p>Also, today I notice that even after reopening the app and beginning a new study session of "All Due Notes" for the day, after studying around 12 notes and closing the app, the file still hasn't updated. I guess a change in study "history" is not something that triggers an update in this file.</p>
<p>Its interesting that some days this file updates upon first open of the app for the day, and sometimes it does not. Maybe has to do how long it has been since I completed the previous day's study session?</p></div>zeppotag:mentalfaculty.tenderapp.com,2010-10-19:Comment/473524032020-05-12T16:15:59Z2020-05-12T16:15:59Zdue notes count when opening the app for first time each day<div><p>I’m not sure. I could actually be confusing that file with the WAL file. In any case, it is well outside our expertise as app developers: it is a database level detail. We have no control over it.</p></div>drewmccormack