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

Saved preset is displayed as "Unsaved Preset" when pressing the stop button (intermittently occuring...) #1155

Closed
SebastJava opened this issue Dec 19, 2023 · 13 comments · Fixed by #1157
Labels
always-fresh Issues that will never become stale bug Something isn't working

Comments

@SebastJava
Copy link

Description

I play one of my saved presets. While this preset is playing, I just take a look at its composition by scrolling up and down through the library. I don't change anything, I am just looking at all the individual sound sources mixed in... Then I press the "stop" button and then the name displayed at the bottom of the screen is: "Unsaved Preset". This leaves me in a somewhat doubtful state: did I save my last tweaks or not? But yes, it was saved and there were no further tweaks, I tested this many times. Unfortunately, it isn't easy to reproduce, it only occurs intermittently !

To Reproduce

  1. Go to Presets and select one of yours...
  2. Go to the library, and take some time to scroll up and down, just to take a look at this complex mix...
  3. Press the "Stop" button at the bottom of your Android phone screen...
  4. See? Your preset is now named as "Unsaved Preset" !

Note

This bug only occurs once in a while. Maybe the key to trigger this bug is just... TIME !? I mean, just keep looking at the library for 5 minutes while listening to your custom preset, and then press the "Stop" button... :)

Screenshots

Screenshot_20231219-104147-LR

Others

  • Device: Moto G Pure
  • Android Version: 12
  • App Version: 2.5.4
  • Downloaded From: Google Play
@SebastJava SebastJava added the bug Something isn't working label Dec 19, 2023
@ashutoshgngwr
Copy link
Member

ashutoshgngwr commented Dec 19, 2023

Thanks for reporting this! iirc, it came up during the implementation, and I had been lazy about it. Nonetheless, I'll try to fix this as soon as possible.

@SebastJava
Copy link
Author

Thanks for this quick reply! I was currently trying to investigate what causes this bug to occur, exactly. Trying to find the exact steps to reproduce... Because this is that kind of mysterious bug that I can talk about, but I am not able to consistently reproduce it every time...

So, my question is: do you have a clear idea of the "steps to reproduce"? Or should I keep trying to find the exact combination of steps to reproduce this bug?

@ashutoshgngwr
Copy link
Member

@SebastJava Thank you for taking the time to investigate it. I don't remember exactly. There may have been several refactors since then. Perhaps it is best not to rely on my vague memory. If I were starting afresh, I'd start here:

fun getCurrentPreset(): SortedMap<String, Float> {
return soundPlayers
.filterValues { state == State.STOPPING || (it.state != SoundPlayer.State.STOPPING && it.state != SoundPlayer.State.STOPPED) }
.mapValues { soundPlayerVolumes[it.key] ?: 1F }
.toSortedMap()
}

Most likely, it is broken. You can also look at SoundPlaybackService, where it is called to update a StateFlow on which the UI elements rely.

@ashutoshgngwr
Copy link
Member

ashutoshgngwr commented Dec 19, 2023

@SebastJava I tried reproducing it myself! I think what happens is when you play a preset, not all sounds will be in the PLAYING state at the same time. A few of them might be in the BUFFERING state. When you hit stop, the sounds in the PLAYING state enter the STOPPING state, while the sounds in the BUFFERING state directly enter the STOPPED state. This is important because SoundPlayerManager#getCurrentPreset and SoundPlaybackService rely on sound states to find the active preset name, and sounds in STOPPED won't be part of the active preset. I hope this makes sense!

To reproduce it, you need to hit stop before all sounds enter the PLAYING state. You can monitor sound states in log messages with the SoundPlayerManager tag. Can you verify this?

@ashutoshgngwr
Copy link
Member

@SebastJava It should be easy to reproduce on a slow network since not all sounds from a preset will be able to buffer adequately to start concurrently.

@SebastJava
Copy link
Author

@ashutoshgngwr I am not really a programmer, but I am willing to learn... Maybe, one day, I will finally find the time, and a quiet environment, and peace of mind, so I can dive into these things more seriously.

I am currently writing this reply on my computer, with the latest Linux Mint Cinnamon OS. But here I am talking about your Noice app on my Moto G Pure cellular phone, with Android 12.

[...] I hope this makes sense!

Yes, I approximately understand your reasoning and it makes sense.

To reproduce it, you need to hit stop before all sounds enter the PLAYING state. You can monitor sound states in log messages with the SoundPlayerManager tag. Can you verify this?

If I understand you correctly, your are saying this bug would only occur when I quickly press "stop", so there are still sounds in the BUFFERING state... But, from my various empirical tests, I get the feeling it just the opposite. This little bug only occurs when I press "stop" after some time, like after 2 minutes or so. I never get this bug if I just play my preset for 10 seconds and then stop.

And... what makes it even weirder is it seems I only get this bug with my custom presets.
This one: https://trynoice.com/preset?v=1&n=Cascades&s=%7B%22brownian_noise%22%3A1.0%2C%22pink_noise%22%3A0.8%2C%22water_stream%22%3A1.0%2C%22white_noise%22%3A0.4%2C%22wolves%22%3A0.5%7D

@SebastJava
Copy link
Author

You can monitor sound states in log messages with the SoundPlayerManager tag. Can you verify this?

@ashutoshgngwr

Sorry, I have trouble understanding this. I don't know how to find any log messages on my Moto G Pure Android 12 phone. Help please!

@SebastJava
Copy link
Author

SebastJava commented Dec 19, 2023

Also, I believe my internet connection isn't so slow. I only use this nice Noice when at home. So, I have my own WiFi connection here. And I am the only user on it and thus I am pretty sure I always get the same steady ▼15 Mbit/s || ▲10 Mbit/s...

@SebastJava
Copy link
Author

Ah, okay, sorry, I had many things on mind at the same time. I think I can quickly find answers on how to get these Android system logs. Still, your help would be appreciated, but otherwise I will probably just find some answers on Google... :)

@SebastJava
Copy link
Author

@ashutoshgngwr All right ! I think I may have finally found the exact strange steps to reproduce...

To reproduce

  1. Go to the Library.
  2. Choose at least one sound that repeats seamlessly, such as pink or white noise.
  3. Choose one sound that repeats with a random delay, such as wolves or thunder.
  4. Save your preset.
  5. Just listen and wait for at least 60 seconds, then press stop while no randomly delayed sound is playing, i.e. no wolf howls or thunder sounds.
  6. See? "Unsaved preset" is now displayed for 5 seconds, during the fade out...

Of course, I can't be sure, but I think I found it. I hope I am not wasting your time. The truth is I am a bit reluctant to dive into this big system logs investigation. It would probably be a fascinating adventure, but I currently have other concerns on my mind. I am busy with other things. This system logs investigation probably sounds easy for you, but the thing is I would have to start by installing the big SDK. This looks like a big adventure. Maybe later?

@ashutoshgngwr
Copy link
Member

Hey @SebastJava! Thank you for taking the time to dig deep and find the exact steps needed to reproduce this. I'll resolve it as soon as possible, perhaps over the weekend.

I hope I am not wasting your time.

You didn't. Your input has been very helpful!

@ashutoshgngwr ashutoshgngwr added the always-fresh Issues that will never become stale label Dec 20, 2023
ashutoshgngwr added a commit that referenced this issue Dec 31, 2023
this helps maintain behaviour parity among contiguous and
non-contiguous sounds, which in-turn helps maintaining the
correct preset state during STOPPING and PAUSING transitions.

resolves #1155
ashutoshgngwr added a commit that referenced this issue Dec 31, 2023
this helps maintain behaviour parity among contiguous and
non-contiguous sounds, which in-turn helps maintaining the
correct preset state during STOPPING and PAUSING transitions.

resolves #1155
ashutoshgngwr added a commit that referenced this issue Dec 31, 2023
this helps maintain behaviour parity among contiguous and
non-contiguous sounds, which in-turn helps maintaining the
correct preset state during STOPPING and PAUSING transitions.

resolves #1155
@ashutoshgngwr
Copy link
Member

@SebastJava I've added a fix to resolve this issue. Since it changes a few components' behaviours at the implementation's lowest level, I'm sceptical that it may cause unwanted side effects. Nevertheless, I've released a new version, 2.5.5, with this fix, and it should be available shortly on GitHub releases, F-Droid and Noice beta on the Google Play Store.

@SebastJava
Copy link
Author

Thanks !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
always-fresh Issues that will never become stale bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants