Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bass] Vibration Stops Working #283

Open
voyager529 opened this issue Mar 21, 2024 · 14 comments
Open

[bass] Vibration Stops Working #283

voyager529 opened this issue Mar 21, 2024 · 14 comments

Comments

@voyager529
Copy link

voyager529 commented Mar 21, 2024

Describe the bug
After flashing the watch, the vibration works fine, but for no more than 24 hours. After this, all vibration ceases, regardless of method.

To reproduce
Steps to reproduce the behavior:

  1. Flash [bass] with AsteroidOS image, and pair to phone.
  2. Use watch normally for a day or so.
  3. Experience total absence of vibrations.

Expected behavior
Vibrations continue to work when notifications arrive.

Screenshots
Inherently unable to screenshot.

Device (please complete the following information):

  • Watch Codename: bass
  • AsteroidOS Builddate 20240314232113
  • Version [1.1 nightly]

Additional context
Loss of vibration does not appear to have any correlation with a lack of communication with the phone.

Vibration does not return after a reboot of the watch.

Vibration does not return after putting the watch into bootloader mode and then continuing.

Once vibration is lost, it does not happen if any debug / test commands are sent from Gadgetbridge.

Once vibration is lost, it does not happen if I use AsteroidOS Sync instead.

Once vibration is lost, it does not happen if I toggle the vibration option in Quick Settings on the watch.

Vibration sometimes happens if I send a 'find my watch' command from Gadgetbridge, but in some cases, it does not happen even then. The loss in the event of a 'find' command seems to loosely correlate with longer uptimes, but not always.

Vibration does return if I re-flash the watch, but only for the same short time.

This issue appeared to happen over the last few nightlies; I've only been using AOS since early March, for context.

@beroset
Copy link
Member

beroset commented Mar 23, 2024

I just wanted to highlight this one piece of information, as verified in our Matrix chat:

Once vibration is lost, it does not happen if I toggle the vibration option in Quick Settings on the watch.

In other words, once it stops working, turning vibration on via Quick Settings (which should normally cause the watch to vibrate) does not make the watch vibrate.

Unfortunately I don't have a bass and so I can't do much to work on this. It doesn't seem to affect other watches.

@putridpete
Copy link

putridpete commented Apr 1, 2024

I'm also suffering the same issue, but in my case rebooting the watch does bring vibration back. I've noticed that the problem seems to happen at some point when reconnecting to my phone while it's on vibration mode, although I suppose it could be coincidence. I have been able to keep vibration on for a few days, provided that I maintain phone and watch synced at all times, don't lose bluetooth connectivity and never send my phone into vibration mode.

I have my bass paired with a OnePlus 8T (kebab) running LineageOS+microG 21 (21-20240319-microG-kebab). Watch itself is on AsteroidOS 1.1-nightly 20240321233039.

Edit: So vibration stopped exactly 24 hours later despite not losing connection or any of the other things I mentioned. Not sure how I got it to run for about 3 days without vibration disabling itself. That said, I can always get vibration back by rebooting.

@jason-kurzik
Copy link

New owner here, my experience more or less matches @putridpete's.

Fresh flash from fully updated stock WearOS, paired with a Google Pixel 5 running latest stock OS.

@jason-kurzik
Copy link

I began working my way backwards through the archives, and I've been going three days with vibration still working on 1.1-nightly 20240216002300

@putridpete
Copy link

putridpete commented May 14, 2024

Great, I've just flashed the same version and will test to see if I also keep vibration going. Much appreciated.

Edit: Unfortunately, twice in a row I have lost vibration after around 24 hours even in the aforementioned previous release. One thing I've noticed is that I tend to lose vibration even earlier if I lose connection repeatedly while using the AsteroidOS Sync app, by say... walking too far away several times.

@jason-kurzik
Copy link

Yes, I noticed this too, my joy was premature.

One thing I've noticed is that I tend to lose vibration even earlier if I lose connection repeatedly while using the AsteroidOS Sync app, by say... walking too far away several times.

That may well track, I've noticed that even when keeping phone close-ish bluetooth connectivity drops quite frequently (bet its the power saving on my phone). I'm going to try swtiching to Gadgetbridge and see if it happens still.

@jason-kurzik
Copy link

jason-kurzik commented May 21, 2024

@putridpete I think I have steps to reproduce, using a fresh nightly flash. No phone connection or bluetooth required.

  • Flash latest nightly (using asteroid-hosttools)
  • Speedrun the tutorial (any way to turn that off?)
  • Set an alarm for +1 minute, vibration works
  • Snooze alarm
  • When snoozed alarm goes off, vibration works
  • Snooze alarm again, vibration breaks till reboot. Bonus bug: The snoozed alarm doesn't fire until after the reboot.

Checking the Alarm code, it looks like 6 months ago there was a commit that changed alarmDialog.snooze() in the snooze handling to alarmDialog.close(), but doesn't do an alarmDialog.dismiss() the way that the other dismiss functions do.

I don't think this is the root cause, because I had this happen without using the alarms, but I'm betting it gets us closer.

@beroset
Copy link
Member

beroset commented May 22, 2024

In answer to your question (turning off the tutorial), yes, you can hold down the on-screen button to bypass it. Thanks for your work in reproducing this! It's a tremendous help.

@putridpete
Copy link

I can confirm that I am able to reproduce this error before and after reflashing the latest nightly. Furthermore, I've noticed that if I set an alarm to go off in 1 minute and hit the confirm button to dismiss the alarm I lose vibration right away every single time until a reboot.

@jason-kurzik
Copy link

jason-kurzik commented May 22, 2024

I flashed the oldest archive I could, 2023-08-23, which also reproduces the 'confirm button to dismiss breakage'.

Edit: Found the old 1.0 release, and this does not reproduce the error.

@MagneFire
Copy link
Member

@putridpete I think I have steps to reproduce, using a fresh nightly flash. No phone connection or bluetooth required.

  • Flash latest nightly (using asteroid-hosttools)
  • Speedrun the tutorial (any way to turn that off?)
  • Set an alarm for +1 minute, vibration works
  • Snooze alarm
  • When snoozed alarm goes off, vibration works
  • Snooze alarm again, vibration breaks till reboot. Bonus bug: The snoozed alarm doesn't fire until after the reboot.

Checking the Alarm code, it looks like 6 months ago there was a commit that changed alarmDialog.snooze() in the snooze handling to alarmDialog.close(), but doesn't do an alarmDialog.dismiss() the way that the other dismiss functions do.

I don't think this is the root cause, because I had this happen without using the alarms, but I'm betting it gets us closer.

Great work on finding this!

Did you also try with Alway-on-Display disabled? That uses some of the alarm mechanics as well (it doesn't use any snoozing logic, but it may also be a potential cause).

@beroset
Copy link
Member

beroset commented May 22, 2024

Just tried this on catfish and it definitely works as expected there, so it does seem to be specific to bass. I'm not sure that adds much value, but it's an observation.

@putridpete
Copy link

putridpete commented May 23, 2024

@MagneFire I already had Always-on-Display disabled when I tried to reproduce jason-kurzik's method, but I get the same result with it on or off; let's see if it's the same case for him.

@jason-kurzik
Copy link

Confirmed, I almost always turn Always-on off. I have not seen a difference in behavior either way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants