App sometimes hangs at fast rise

[robster7674]

Over time I have witnessed with my wife's xdrip setup that when a fast rise in bg occurs, the app stops speaking bg values. Eventually we notice that there are no readings anymore and then when we check the app on her iPhone, there is a warning about the fast rise blocking things. I'd say typically this happened once/twice per week, but it is always at times when the app is need most, that's the irony.

Is it possible that the alarm notification blocks processing readings under certain circumstances? Is there any logging I can enable and provide, after the next time it happens?

Device is iPhone 8 Plus, iOS 15.

Thank you for making this app!

[JohanDegraeve]

you can send logs with an option in the settings, if you want you can send the to yourself first

[robster7674]

Thanks Johan. Today already I got "lucky": from what I remember, I saw a value of 8.4, and after a while we realized that for quite some time there had not been any spoken bg values. When checking the app it was indeed hung, and restarting it showed a 9.4. Just before this happened I enabled the various log settings, resulting in the attached log files, I hope these shine some light on the issue. I'll see if I can get anywhere with the logs myself. One thing: I noticed is that bg values appear as mg/dl in the logs, right? It would be nice to have them follow the setting of the app, which in my case is mmol/l.

[JohanDegraeve]

Better not to add logs here, because I contains glucose values. There's many fast rise alert is raised, you can see "in checkAlert, raising alert fastrise", but always the app continues to work.

what actually happens, I think

• you're having a fast rise alert, this plays a sound
• the logic is that if a sound is being played, bg reading will not be spoken, because it uses the same soundplayer Actually you should be hearing the alert, or maybe the iphone volume is too low?

This wouldn't happen if your alarms would not have enabled 'override mute', because in that case the alarm is not played with the soundplayer, but by using the sound in the notification. But then you risk that you may have muted the phone, and wouldn't hear the alarm.

[robster7674]

Well, the issue is not that we don't hear sounds or that the volume is too low, as there are notifications for other apps prtty much all the time, and the phone volume is never (too) low. The issue is that at a certain point, in hindsight typically a fast rise, the app stops altogether, there are no bg values sent anymore and there are also no notifications anymore, whether they are alarms or spoken readings. Then after a while, typically when she starts feeling off due to the high bg, we check the app and notice it's hanging again. However, based on your comments above this did not happen in this case. I will keep monitoring and ensure I send logs next of such occurrence.

I noticed that the app seems to behave a bit unstable (crashes sometimes) when the various logs and debug output are enabled. Is it enough to send just the standard logs after the problem happened again?

[JohanDegraeve]

Why do you think it 'crashes'? because in the logs I don't need see. one app restart. If it would have crashed, you would have restarted the app at least once to send the logs. There's no normal notification if there's already a. notification for an alarm (an alarm is actually a notification). In the logs there's for instance in the last log (.0.) 8 times "in checkAlert, raising alert fastrise", are you net hearing that alarm? Maybe it's an alarm configured without sound?

the logs are always there, it's three rotating files, there's a maximum size. If you have debug level enabled, it's max 8 hours in your case. If it happens (or think it does) you just need to send the logs and note the time when it happened. You can actually disable the debug level.

[robster7674]

When I tried to send a test report to myself, the app "crashed", i.e. it was closed without any notification. Some time later when I started the app again, indeed to send logs, I received both the log set of the previous attempt, and a second set of logs, in my expectation capturing the issue (but apparently it didn't). Not sure why the app closed at sending the report, interesting if that does not show in the logs, but I agree with your logic on the restart. I'll keep an eye on that and for now disable the debug level.

The alarm is configured with sound and we typically hear it. It's a bit hard to explain the exact situation in text.

For now, as soon as it happens again I will send in new logs. Thank you for your support so far.

[paulplant]

@robster7674 , we'll close this issue for now as we didn't really advance very far to see if it was a real bug or issue. Feel free to open a new issue in the future if it happens again.