Closed neirfeno closed 2 years ago
Please can you provide the xDrip version you are using and the version as it worked before?
I can verify that indeed this is still an issue.
Additionally, I can't answer the last version it "worked" it has never worked for me.
@neirfeno We still don't know which "Previous versions" you are referring to. I did not have this problem with any of the versions I'm using. Maybe, this is related to the alert tone. I'm using the same alerts the Dexcom app is using. These alerts are very short like a "beep beep". Afterwards, nothing is heard until the alarm is re-raised.
This has been an issue for every version I've used. That probably means the bug is linked to a phone (Samsung Galaxy S10) since I've only ever used xDrip on this phone. I'm on Android Version 11.
The bug is only present on the alert that has "Override Phone Silent" and "Force Speaker" enabled. The other alert I have only sounds once and respects the Re-raise time. Those two options probably do some pretty crazy stuff with respect to alerts, so I would look into that code.
This is a key function, because I would like to place my phone in silent mode sometimes but still get a "super high" alert. However, I would like that to only beep beep once.
Alerts that override the silent mode utilize the PlayFile method-
I'm not sure why PlayFile utilizes MediaPlayer synchronously as opposed to Async, but it does. This file has only really been touched by @jamorham, so maybe he can answer that. Maybe just because alert tones are always local files and not streams.
There's no explicit call to setLooping(false). I would imagine that it defaults to false, but hey, my phone is looping that sound, so maybe throw a mediaPlayer.setLooping(false) in there after it's started.
I have force speaker and override silent mode enabled on all my alerts. I have never experienced this problem. I have used xDrip with Android 6, 8, 9, and 11 over the years, always with force speaker and override silent mode enabled.
I'm not sure why PlayFile utilizes MediaPlayer synchronously as opposed to Async, but it does.
Declaring a method as synchronized
has nothing to do how the MediaPlayer plays a file. It is only used to block other threads of xDrip accessing the method (PlayFile
in this case) at the same time. For this particular case it is necessary because the global instance variable mediaPlayer
is modified (object is released, nulled and created again). This should not be done by more than one thread at the same time.
Beside the method declaration, you are still right that MediaPlayer does not play the sound asynchronously.
There's no explicit call to setLooping(false). I would imagine that it defaults to false, but hey, my phone is looping that sound, so maybe throw a mediaPlayer.setLooping(false) in there after it's started.
Please can you modify PlayFile
according to https://stackoverflow.com/a/38821524/10373188 and test whether this solves your problem? The linked solution also enables asynchronous playback and releases the MediaPlayer on completion.
@noctividus Does the alarm still sound continuously with releases after April 12, 2022?
This appears to be fixed in later releases. Thanks for the support!
On Thu, May 5, 2022 at 5:34 AM Navid @.***> wrote:
@noctividus https://github.com/noctividus Does the alarm still sound continuously with releases after April 12, 2022?
— Reply to this email directly, view it on GitHub https://github.com/NightscoutFoundation/xDrip/issues/1418#issuecomment-1118494306, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHLLT4RZB5C5L7VQ2GPNZDVIO56DANCNFSM4QJ7BUHQ . You are receiving this because you were mentioned.Message ID: @.***>
Issue continues... I always used samsung phones, and always had this issue. Alarm repeat every 30 seconds up to you disable. Annoying, but a lot years with it....
@jamorham Is there any way you can reproduce this?
@pablodr350 please confirm xDrip version you are using? If not using the latest nightly version please try that to check the bug is still present, it may already be fixed. If bug still exists, please describe in detail what happens and what you think should happen instead.
Hi, usually update the nightly version every 1/2 months, now withy 2122051915, but I will update to 2122072308 now. This always happened with all samsungs I had... S5... S8... and now S20.
Alert level trigger, and if you don´t SNOOZE, it will continue to sound every 20-30 seconds continuosly (I know because sometimes I can´t touch it and I have to wait with this sound a lot time and even thinking to throw the phone :) ). It never stops. you need snooze (with app or phone ie). I think, the option that say RE-RAISE EVERY X MINUTES IF UNACKNOWLEDGED (ie, I have 10 minutes) would must work, sound one alert, and wait 10 minutes to sound again (not 30 seconds)
at this time, maybe not solution, but yes, desn´t works correctly.
thanks¡¡¡
@pablodr350 Why did you post in this closed issue? This issue is very particular. I assumed you had read this issue and understood every detail of it.
You can open a discussion and we will work with you to resolve it. If you don't snooze an alert, it is not supposed to stop on itself.
Would you please open a discussion using the following?
https://github.com/NightscoutFoundation/xDrip/discussions
If it ends up being related to an existing issue, I will let you know.
fwiw, I have often experienced this problem as well (currently with version 23ccbd1-2023.07.16, but have seen this for years). The problem, however, seems to occur intermittently. i.e. alarms will often sound and only occur once and other times they'll repeat endlessly until I restart the device.
Here's what I see in the Error and Event List after the problem just occurred:
13:47 MissedReadingService. Aggressively restarting collector service due to lack of reception: backoff: 240
13:47 Other Alert. BG Readings Missed (@13:47)
13:47 AlertPlayer. SnoozeOnNotificationDismissService called source = bg_missed_alerts shown for: 14 seconds
13:47 BluetoothHeadset. Bluetooth Audio disconnected:
But now, after restarting the device, the alarm has occurred again, but this time it only played once. :-/
The issue occurs for me on a Pixel 5a (xDrip is only used for remote monitoring/alarms, collecting data from a nightscout instance). Alarm config settings are below.
@rustymonkey The next time this happens, please record the sound and let us hear it. Also, play the same alert once by tapping on test and let us hear that as well.
@Navid200 here's an event log from tonight. One minute goes by really fast when you're doing something else (like washing dishes or phone is on the other side of a room when in public). I've been using xDrip for the better part of a decade but have only used alerts for my daughter's phone since mid-2021.
Have used Alpha, Beta, & Stable versions. I think this problem has always existed for us. We're kind of used to it but it's also wildly infuriating sometimes. Using custom Dexcom tones for all our alerts. Haven't tried with standard xDrip ones because of standardization and audio recognition. Happens with all set alerts (high, low, persistent, etc)
Side note: when it beeps, it does it at full volume
Version: 3e86af7-2023.11.14 Code: 2123111417
@thederekFawcett You have posted in an existing issue. Why is that?
Can you tell us how to recreate this problem? I don't have a Samsung. I have Pixel, Motorola and Asus. When I snooze an alert, it stops.
@thederekFawcett You have posted in an existing issue. Why is that?
Can you tell us how to recreate this problem? I don't have a Samsung. I have Pixel, Motorola and Asus. When I snooze an alert, it stops.
This is before you dismiss (I never snooze) it. The problem is when it first alarms.
@thederekFawcett Then, it has nothing to do with this issue, as explained in the very first post.
Open a discussion and explain what the problem is and we can talk about it. Put yourself in the shoes of someone who has not experienced what you consider to be a problem. And please don't continue the conversation here.
The thing is, AlertPlayer.java hasn't been touched in a long time. There hasn't been any work done on this bug. Every time people report the problem, the developers basically ask them to "prove it" like it isn't happening to them. If they can't reproduce it, then it isn't happening. Then, after an android update or something, it goes away for that particular user. That's what happened to me. And to be clear, I never did this:
https://github.com/NightscoutFoundation/xDrip/issues/1418#issuecomment-961479682
And, nobody ever experimented with changing how xDrip plays files. I didn't want to set up an android dev environment and build, and since it had gone away from my phone, it would have been more difficult to test. For the record, this issue is back for me with my new phone, but I just can't deal with this nonsense so I disable alerts in xDrip and use my omnipod dash app to alert.
Until someone goes in and looks at how alert sounds are played and actually finds a bug and fixes it, this issue is going to keep popping up. And, if magical code fixes equate to closed tickets, then you're probably going to get people trying to reopen tickets because the general rules are "look for existing issues" first and then open a new ticket none exist. From this thread, it's pretty crystal clear that this is an ongoing issue, and from the commits, it's pretty clear that nothing has been done.
On Tue, Feb 13, 2024 at 6:06 AM Navid @.***> wrote:
@thederekFawcett https://github.com/thederekFawcett Then, it has nothing to do with this issue, as explained in the very first post.
Open a discussion and explain what the problem is and we can talk about it. Put yourself in the shoes of someone who has not experienced what you consider to be a problem. And please don't continue the conversation here.
— Reply to this email directly, view it on GitHub https://github.com/NightscoutFoundation/xDrip/issues/1418#issuecomment-1941596338, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHLLT53AGAEH7QTA3D32TDYTNXOTAVCNFSM4QJ7BUH2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJUGE2TSNRTGM4A . You are receiving this because you were mentioned.Message ID: @.***>
I believe you.
The only way I can fix a bug is to recreate it first. Then, I can verify that it has been fixed before submitting it for review. Even if I experience a bug myself and want to fix it, I need to include in my submission how to recreate the problem. Otherwise, it will not be accepted. And it shouldn't be.
I am looking at alert player a lot because I am working on several projects related to it. There is nothing in there I can look at to fix a problem I don't see.
I have been using xDrip for almost 6 years now, 24/7, with Android 4 all the way up to 14. I have never experienced an alert that kept going. There is a lot that could vary from phone to phone. I have never had a Samsung.
Everyone is welcome to contribute. We are all volunteers. If anyone can fix a problem, we encourage them to come forward and share their expertise.
The barrier to actually set up a dev environment is huge. Not only Java, Android and all the dependencies, but also just an environment to test the apk on a phone with simulated high/low values coming in. You guys seem to have that. What I can do is make a recommendation:
Throw this in there right below mediaPlayer_=
new MediaPlayer();
mediaPlayer_.setLooping(false);
No guarantees...but it seems like a no-brainer to start going after this issue. If it doesn't break the player, I would say it can stay in beta branches for a while before getting merged up.
I will never just add something to the code because it "may" fix something. The code is already too complicated.
Even some developers don't appreciate that and keep adding kill switches. And then, users say why is xDrip so complicated?!
I don't have a Samsung. So, I cannot test this. Developers who have Samsung have asked please tell us how to recreate this and no one has been able to explain it. So, it is not like everyone who has Samsung is experiencing this. There are many xDrip users who use Samsung. This is not a problem they all experience.
It is very likely you have a setting or customization that is causing it.
If xDrip was looping, why would only Samsung play the looping and other phones ignore it?
If this is xDrip looping, it should show in logcat, right? Can you set up an old Samsung phone to use the fake data source so that it would repeatedly trigger alerts? https://navid200.github.io/xDrip/docs/FakeDataSource.html Connect the phone to Android studio and bring up logcat. Can you show in the logcat logs that it is xDrip mediaplayer that keeps asking the phone to repeat the sound?
We have already set looping to false:
https://github.com/NightscoutFoundation/xDrip/blob/f96d4e5ba282bf385dfc2ea8b070b39cb8b4303e/app/src/main/java/com/eveningoutpost/dexdrip/utilitymodels/AlertPlayer.java#L384
I am open to suggestions other than buying a Samsung. I would like to fix this. How can I?
Has anyone experiencing this checked to see if there may be a Samsung setting like the one linked below that could be causing this behavior? https://www.samsung.com/za/support/mobile-devices/how-do-i-set-up-repeat-notifications-for-messages-on-my-samsung-galaxy-smartphone/
I'm no longer using xDrip, but fyi, I was experiencing the issue on a Pixel 5a so it's probably not Samsung-specific.
Previous versions of the app would sound the alarm once, then repeat it as specified by the
Re-raise every x minutes if unacknowledged
setting. Current version alarms continuously, clicking on the notification opens the app alarm still going, try and select the snooze time (alarm still blaring), and click snooze. This is extremely frustrating. Please, please, please put it back the way it was. I believe this is a bug because otherwise the re-raise setting is pointless.