ascending alert switches of the radio/mp3

[fezulin]

Version: Beta5, 2.0.5_1

Hi, I observed a behaviour about sounds and alerting of xDrip-App.

To reproduce the observation:

1. Settings / Bg Alerts Settings / Bg alerts profile : „Ascending“
2. Settings / Speak Readings: activated
3. Plug earphones into mobile, respectively your ears, switch on the radio (or play mp3-file).
4. Do something that lets your BG fall below your alerting value. (Such like riding a bicycle.)

What I observed:

1. First, xDrip will tell the BG values. (What is fantastic and as expected.)
2. In case of BG falls below the first value for alerting, the radio will suddenly be switched of, or better: the volume will be switched to minimum.
3. If you do nothing, it will take some time, until the volume will come up with the next interval of BG alerting.
4. I had this experience with "xDrip default sound" as well as with a manually selected "System sound/Alarm".

If I had a free wish:

1. It is correct and expected that the first alert interval would be with minimum volume.
2. I would prefer, if xDrip could detect the current volume setting, before changing it to minimum, “play” the alert sound and then change back to originally defined volume.
3. This would allow me to ride the bike (and listen to the radio/mp3-file) until there is a situation, that allows to stop and take care about the alert. Because the mobile is well stored in a pocket, I cannot acknowledge the alarm while riding the bike. But I would prefer to listen to radio (or e.g. an audiobook) until I decide to stop.

What would you say - is this a behaviour that could be changed? Best regards, fezulin

[tzachi-dar]

Thanks for your detail report.

Looking at the code what you have asked is exactly what I have implemented. But looks like it does not work.

What android version are you using? Also, is your alert an mp3 file or a ringtone? It seems to me that it is a file since we don't decrease the volume for the other alerts.

Currently I'm working on other things, but hopefully I can look at it next week.

So, please let me know what alert you are using. Also, is your phone rooted?

Thanks Tzachi

On Thu, Feb 11, 2016 at 10:36 PM, fezulin [email protected] wrote:

Hi, I observed a behaviour about sounds and alerting of xDrip-App.

To reproduce the observation:

1. Settings / Bg Alerts Settings / Bg alerts profile : „Ascending“
2. Settings / Speak Readings: activated
3. Plug earphones into mobile, respectively your ears, switch on the radio (or play mp3-file).
4. Do something that lets your BG fall below your alerting value. (Such like riding a bicycle.)

What I observed:

1. First, xDrip will tell the BG values. (What is fantastic and as expected.)
2. In case of BG falls below the first value for alerting, the radio will suddenly be switched of, or better: the volume will be switched to minimum.
3. If you do nothing, it will take some time, until the volume will come up with the next interval of BG alerting.
4. I had this experience with "xDrip default sound" as well as with a manually selected "System sound/Alarm".

If I had a free wish:

1. It is correct and expected that the first alert interval would be with minimum volume.
2. I would prefer, if xDrip could detect the current volume setting, before changing it to minimum, “play” the alert sound and then change back to originally defined volume.
3. This would allow me to ride the bike (and listen to the radio/mp3-file) until there is a situation, that allows to stop and take care about the alert. Because the mobile is well stored in a pocket, I cannot acknowledge the alarm while riding the bike. But I would prefer to listen to radio (or e.g. an audiobook) until I decide to stop.

What would you say - is this a behaviour that could be changed? Best regards, fezulin

— Reply to this email directly or view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/274 .

[fezulin]

Hi tzachi-dar, what a pity, that it seems not to work as planned. (At least in my specific case.)

I have a Motorola Moto G, Android 5.1. Phone is not rooted.

I defined the alert sound as follows:

• settings / Bg Level Alerts / Create Low Alert
• define value
• Alert Tone: choose file

Variant A

• System Sound/Alarm
• I selected one of them ("Ping" and another time I selected "Centaurus")
• Save Alert

Variant B

• Selected "Default xdrip sound"
• Save Alert

Both variants had the same behaviour. Best regards, fezulin

[tzachi-dar]

OK, I'll try that on my phone and if it will work, here I'll send you a version with printing that will let us know more.

Just some patience.

Thanks Tzachi

On Thu, Feb 11, 2016 at 11:34 PM, fezulin [email protected] wrote:

Hi tzachi-dar, what a pity, that it seems not to work as planned. (At least in my specific case.)

I have a Motorola Moto G, Android 5.1. Phone is not rooted.

I defined the alert sound as follows:

• settings / Bg Level Alerts / Create Low Alert
• define value
• Alert Tone: choose file

Variant A

• System Sound/Alarm
• I selected one of them ("Ping" and another time I selected "Centaurus")
• Save Alert

Variant B

• Selected "Default xdrip sound"
• Save Alert

Both variants had the same behaviour. Best regards, fezulin

— Reply to this email directly or view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/274#issuecomment-183067380 .

[tzachi-dar]

OK, seems that the notification that is not called after media player finishes.

There is the following line in log: Handler (android.media.MediaPlayer$EventHandler) {426e46a0} sending message to a Handler on a dead thread.

Need to understand why, probably look at: http://stackoverflow.com/questions/8690198/sending-message-to-a-handler-on-a-dead-thread-when-getting-a-location-from-an-in

http://stackoverflow.com/questions/8690198/sending-message-to-a-handler-on-a-dead-thread-when-getting-a-location-from-an-in

[fezulin]

My capacity is sufficient to report an observed behaviour and to find a way to reproduce it. But I am not able to understand the source code. So I will be waiting in a relaxed and patient way for a progress in this issue. :)

[tzachi-dar]

From the android documentation:

In order to receive the respective callback associated with these listeners, applications are required to create MediaPlayer objects on a thread with its own Looper running (main UI thread by default has a Looper running).

We are using Notifications extends IntentService that has a looper. However, it quits before we exit the loop. Trying to call looper loop before the function returns does help (that is the callback is being called) but I can't seem to find a way to stop the loop. In other words, calling looper.quit(); causes xDrip to be terminated.

Force finishing activity com.eveningoutpost.dexdrip.viewer/com.eveningoutpost.dexdrip.Home

Consumer closed input channel or an error occurred. events=0x9 02-20 23:48:05.738 W/ActivityManager( 750): Force finishing activity com.eveningoutpost.dexdrip.viewer/com.eveningoutpost.dexdrip.Home

02-20 23:48:05.748 W/InputDispatcher( 750): channel '43014d48 com.eveningoutpost.dexdrip.viewer/com.eveningoutpost.dexdrip.Home (server)' ~ Consumer closed input channel or an error occurred. events=0x9

02-20 23:48:05.748 E/InputDispatcher( 750): channel '43014d48 com.eveningoutpost.dexdrip.viewer/com.eveningoutpost.dexdrip.Home (server)' ~ Channel is unrecoverably broken and will be disposed!

02-20 23:48:05.758 W/InputDispatcher( 750): Attempted to unregister already unregistered input channel '43014d48 com.eveningoutpost.dexdrip.viewer/com.eveningoutpost.dexdrip.Home (server)'

02-20 23:48:05.758 I/WindowState( 750): WIN DEATH: Window{43014d48 u0 com.eveningoutpost.dexdrip.viewer/com.eveningoutpost.dexdrip.Home}

02-20 23:48:05.768 D/Zygote ( 184): Process 3185 terminated by signal (11)

02-20 23:48:05.768 W/ActivityManager( 750): Exception thrown during pause

02-20 23:48:05.768 W/ActivityManager( 750): android.os.DeadObjectException

02-20 23:48:05.768 W/ActivityManager( 750): at android.os.BinderProxy.transact(Native Method)

02-20 23:48:05.768 W/ActivityManager( 750): at android.app.ApplicationThreadProxy.schedulePauseActivity(ApplicationThreadNative.java:660)

02-20 23:48:05.768 W/ActivityManager( 750): at com.android.server.am.ActivityStack.startPausingLocked(ActivityStack.java:761)

02-20 23:48:05.768 W/ActivityManager( 750): at com.android.server.am.ActivityStack.finishActivityLocked(ActivityStack.java:2443)

02-20 23:48:05.768 W/ActivityManager( 750): at com.android.server.am.ActivityStack.finishTopRunningActivityLocked(ActivityStack.java:2320)

02-20 23:48:05.768 W/ActivityManager( 750): at com.android.server.am.ActivityStackSupervisor.finishTopRunningActivityLocked(ActivityStackSupervisor.java:2050)

02-20 23:48:05.768 W/ActivityManager( 750): at com.android.server.am.ActivityManagerService.handleAppCrashLocked(ActivityManagerService.java:9548)

02-20 23:48:05.768 W/ActivityManager( 750): at com.android.server.am.ActivityManagerService.makeAppCrashingLocked(ActivityManagerService.java:9441)

02-20 23:48:05.768 W/ActivityManager( 750): at com.android.server.am.ActivityManagerService.crashApplication(ActivityManagerService.java:10086)

02-20 23:48:05.768 W/ActivityManager( 750): at com.android.server.am.ActivityManagerService.handleApplicationCrashInner(ActivityManagerService.java:9637)

02-20 23:48:05.768 W/ActivityManager( 750): at com.android.server.am.NativeCrashListener$NativeCrashReporter.run(NativeCrashListener.java:86)

02-20 23:48:05.778 I/ActivityManager( 750): Process com.eveningoutpost.dexdrip.viewer (pid 3185) has died.

So, if anyone knows how to continue with this approach, I'll be thankful, otherwise I'll move to creating mplayer on the ui thread.

[tzachi-dar]

OK, I have a fix. fezulin, Do you want to test it before we commit it?

[fezulin]

You have a fix?! Fantastic! And: Yes, I would like to test this fix! But - I cannot create an APK-file. Can I download such a file somewhere?

[tzachi-dar]

I'll be running some more tests on this, than I'll send you the APK, hopefully tonight.

Thanks Tzachi

On Wed, Feb 24, 2016 at 9:49 AM, fezulin [email protected] wrote:

You have a fix?! Fantastic! And: Yes, I would like to test this fix! But - I cannot create an APK-file. Can I download such a file somewhere?

— Reply to this email directly or view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/274#issuecomment-188129745 .

[tzachi-dar]

tough luck here.

I have been running with the fix while playing an alert once a minute. This has worked well on android 4.4 but when running it on android 5.0 there was a problem.

xDrip has had an anr. Many traces files have been created, but none of them had any thing to do with xdrip code or the process itself.

Here is an example file: traces_com.eveningoutpost.dexdrip.viewer_2016-02-25-08-50-54_0004.txt

Looking at the logcat from that time it seems that the problem is not related to my new code but rather to DailyIntentService

02-25 09:34:11.190 W/ActivityManager( 731): Timeout executing service: ServiceRecord{24ffa133 u0 com.eveningoutpost.dexdrip.viewer/com.eveningoutpost.dexdrip.Services.DailyIntentService} 02-25 09:34:17.438 E/ActivityManager( 731): ANR in com.eveningoutpost.dexdrip.viewer 02-25 09:34:17.438 E/ActivityManager( 731): PID: 5350 02-25 09:34:17.438 E/ActivityManager( 731): Reason: Executing service com.eveningoutpost.dexdrip.viewer/com.eveningoutpost.dexdrip.Services.DailyIntentService

I have seen this happened before, so not sure if this is related or not.

Also adding the logcat file. file3.txt

If anyone knows how to get to the call stack of the faulting thread that would be great (phone is not rooted).

I'm repeating the experiment for the weekend.

[tzachi-dar]

So, this weekend all worked well. Continuing to run for another week, to have more confidence.

[tzachi-dar]

This is working well for a week now. I'll continue to run for the weekend, but fezulin you can start testing it.

I'm attaching a signed apk that you simply have to download, rename app-xDrip-release.apk and install.

Please let me know if this is working well for you.

[tzachi-dar]

Looks like I did not upload the correct file, will fix it in a few minutes.

[tzachi-dar]

OK, attached the correct file this time.

[fezulin]

Hi Tzachi, thank you for working on this issue! I just did a quick test.

With following conditions: 1.) Android 5.1, mobile is not rooted 2.) Alert ascending, with „System Sound/Alarm” 3.) Music player playing mp3 file. 4.) BG falls below an alert value. 5.) Complete test repeated with "BG rises above an alert value", same results. 6.) Complete test repeated with radio instead of mp3-player, same results.

With following result: 1.) Alert is coming up first: no acoustic signal at all (ok), music is played continuously with unchanged volume. (ok) 2.) When “not reacting” on alert, the alert is repeated every minute (ok) 3.) Alert is coming up 1st repetition: music is switched to mute for some seconds (ok), but no alert signal can be heard. (unexpected, but ok) 4.) Alert is coming up 2nd repetition: music is played continuously with just slightly changed volume (ok), alert signal is played parallel to music and can be heard. (ok) 5.) Alert is coming up 3rd repetition: music is played continuously but much louder volume (ok), alert signal is played parallel to music and can be heard. (ok) 6.) Alert is coming up 4th repetition: music is played continuously with “brain blasting” volume (ok), alert signal is played parallel to music and can be heard. (ok)

Summary: 1.) You were definitely working on the correct parameters. (ok) 2.) Music is played continuously – just as wished. (ok) 3.) In my tests the music appeared to be louder, than the alert signal. If it was possible, to get it the other way around, I would prefer that. (ok, with a slight possibility for further improvement of the behavior.)

[tzachi-dar]

Hi fezulin,

I'm glad to hear that we have made good progress in solving the issue.

I believe that the fact that the alert signal is not strong enough, is simply because of the file that you are using for alert. You can try and use a program like http://www.mp3volumer.com/ in order to increase the volume of the file, and than I believe that alert will be louder than other music.

(just take care of your ears if you are using earphones...)

Tzachi

On Thu, Mar 3, 2016 at 4:41 PM, fezulin [email protected] wrote:

Hi Tzachi, thank you for working on this issue! I just did a quick test.

With following conditions: 1.) Android 5.1, mobile is not rooted 2.) Alert ascending, with „System Sound/Alarm” 3.) Music player playing mp3 file. 4.) BG falls below an alert value. 5.) Complete test repeated with "BG rises above an alert value", same results. 6.) Complete test repeated with radio instead of mp3-player, same results.

With following result: 1.) Alert is coming up first: no acoustic signal at all (ok), music is played continuously with unchanged volume. (ok) 2.) When “not reacting” on alert, the alert is repeated every minute (ok) 3.) Alert is coming up 1st repetition: music is switched to mute for some seconds (ok), but no alert signal can be heard. (unexpected, but ok) 4.) Alert is coming up 2nd repetition: music is played continuously with just slightly changed volume (ok), alert signal is played parallel to music and can be heard. (ok) 5.) Alert is coming up 3rd repetition: music is played continuously but much louder volume (ok), alert signal is played parallel to music and can be heard. (ok) 6.) Alert is coming up 4th repetition: music is played continuously with “brain blasting” volume (ok), alert signal is played parallel to music and can be heard. (ok)

Summary: 1.) You were definitely working on the correct parameters. (ok) 2.) Music is played continuously – just as wished. (ok) 3.) In my tests the music appeared to be louder, than the alert signal. If it was possible, to get it the other way around, I would prefer that. (ok, with a slight possibility for further improvement of the behavior.)

— Reply to this email directly or view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/274#issuecomment-191791869 .

[tzachi-dar]

My test phone continues to run well with this fix. Creating a new alert every one minute.