Thinking if the reboot is the keyword here. There is an old bug, somewhat slipped through the cracks, that if the ringtone file is stored in SD card and the ambience gets activated before SD card is mounted, it can remove ringtone setting as the file doesn’t exist. Trying again I’m not immediately able to reproduce now that either, but that could be the first thing recheck and handle more robustly.
No. I’ve tested it really thoroughly and it doesn’t take a reboot to get the sounds replaced. As you can see on the videos, there is no reboot there, a simple switch between two ambiences is all it takes for the sounds to get totally screwed.
The location of the ringtone file doesn’t have any impact on it, either. As I wrote in the discussion, I tested it with sounds from SD card, internal storage, and even with “built-in” default Jolla sounds – same result.
The only thing that does have a connection with reboot is the disappearing of sounds on the Ambience settings page. This is what happens after a reboot, or after an ambience switch.
Just setup all the sounds on an ambience settings page (ringtone, sms, email, chat, calendar, alarm clock), set that ambience as active, reboot, then go again to that ambience’s settings, and voila! only calendar and chat remain visible and all the remaining items are gone.
As for possible causes, in ~/.local/share/system/privileged/Ambienced there are 3 mysql database files holding ambience settings, which have the following extensions: .sqlite, .shm and .wal. As far as I understand it, the .sqlite is the main database, whereas .shm and .wal are kind of temporary (work) files. I’ve noticed that the .sqlite file does not get updated upon an ambience change or modification of ambience settings (e.g. its sounds). I’ve just changed an ambience, modified its sounds, switched to another ambience, switched back to the initial ambience, rebooted, and the main .sqlite database remained remained untouched even after reboot. Its date of last modification is weeks ago.
I strongly suspect yet another access problem caused by Sailjail.
I can’t really tell from the videos if there’s a bug in the ambience switching or not. The behavior there is perfectly fine if the latter ambience didn’t have those tone settings. The question being in what scenario the setting get removed.
Tried again rebooting with a custom ambience which has all the tone setting. This time the one having ringtone on SD card got removed so the race condition for that still exists it seems.
Sailjail unlikely involved. It’s not used for the homescreen, ambienced nor the settings app.
But it was clearly stated many times that both ambiences have all tones configured, and that switching between them causes that sounds (ringtone, sms, email, clock alarm) of the first ambience get replaced by sounds from the other one, only leaving chat and calendar sounds intact. In the bug report, in the “Steps to reproduce” part, it is clearly stated that:
I also wrote in the bug report (and provided a screenshot of it) that on the Ambience page sound settings of all tones but chat and calendar DISAPPEAR upon reboot:
So what’s still missing?
Oh well… when I find some time for it, I guess I’ll have to record yet another video including the view of Ambience settings, or else, clearly, we won’t move a step forward past debating about what the videos show or don’t show.
So, here’s the new video:
It shows the following:
- 00:00 - 00:15 - Water ambience is active. Its settings page is shown where you can see that all sounds are configured.
- 00:20 - 01:40 - Reboot.
- 01:46 - 02:00 - Again Water ambience settings are shown, where you can now see that ringtone, SMS, email and alarm clock sound settings have permanently DISAPPEARED during the reboot, and only calendar and chat sounds (Jolla default, “built-in” tones) remained.
- 02:02 - 02:13 - Settings of another ambience called “BlackBerry Blue 2” are shown, where you can see that all sounds are set to “No sound”
- 02:20 - 02:22 - “Audio and Feedback” settings page is shown, where you can see that all sounds from the “Water” theme are still active after reset, even though they DISAPPEARED from the “Water” ambience settings page (as shown at 01:46 - 02:00), which makes it completely inconsistent. And they are not only still shown there, but they actually still DO WORK normally.
- 02:23 - 02:24 - “BlackBerry Blue 2” ambience gets activated (which has all sounds set to “No sound”). All sounds correctly change to “No sound”, which can be instantly seen on the “Sounds and Feedback” settings page.
- from 02:40 - I am switching back to “Water” ambience. As you can instantly see on the “Sounds and Feedback” settings page (which gets updated on the fly), at this point sounds get TOTALLY SCREWED UP. Ringtone, SMS, email and alarm clock (i.e. all those tones which disappeared from ambience settings during reboot) are not switched to what the “Water” ambience used to have configured but they all remain at “No sound” setting from the “BlackBerry Blue 2” theme. Only calendar and chat sounds (i.e. the ones which did not get removed from ambience settings during reboot) get correctly changed to what they should be.
To recap:
- a simple reboot WIPED settings of ringtone, SMS, email and alarm clock (i.e. all custom tones) of a currently active ambience, without the user being notified about it in any way other than that those settings silently disappeared from that ambience’s settings page (but at the same time they were preserved on the Settings / Sounds and Feedback page and they continued to normally work)
- it was then enough to switch to any other ambience and back to the initial ambience for the sounds to get totally screwed up, ending up with a mixture of sounds (or - even worse - “No sound” settings) from both ambiences.
- As the ambience that was active during reboot has lost its rintone, sms, email and alarm clock settings permanently, enabling that ambience no longer sets up those sounds but from now on they are always preserved from the ambience you’re switching from. That of course without the user knowing anything about it, which in case of the “No sound” setting is a perfect way to miss important calls, emails and messages.
Finally, NO, this problem is NOT limited to only files located on SD card and it is NOT only triggered by reboot. Ambienced INSTANTLY reacts the very same way (i.e. by SILENTLY REMOVING the corresponding sound from active ambience’s settings without ever notifying the user) ANYTIME, upon ANY, even just very temporary, problem with accessing a sound file that’s set in currently active ambience, regardless of the location. The very moment that Ambienced (silently, in the background) is signaled that some sound file or path to it becomes inaccessible (even just for a fraction of second and for literally any reason), it instantly and permanently (silently, in the background) removes that sound from the current ambience’s settings.
Which can be checked with a very simple test: select a sound file from e.g. ~/Music as ringtone, then do ANYTHING to make that file temporarily unavailable, even just for a few seconds: e.g. rename it, or move it to some other folder, or rename the parent folder, et cetera. Then after merely a few seconds undo your changes to the file to restore access to it. Now go to settings of active ambience and see how that sound got PERMANENTLY REMOVED from there, even though you restored access to it before you even opened the ambience settings or did any ambience related operation.
The following video shows how sound file named “Pigulka” (located in /home/defaultuser/Music) is set up as active ambience’s ringtone. Then, to simulate temporary access problem to that file, I renamed that file, and after merely a few seconds I renamed it back to what it was. All that without opening the Ambience settings or doing any ambience related modifications in the meantime. But it was enough for that tone to get instantly, permanently and silently removed from active ambience’s settings.
I would say that it is a pretty bad design to use user’s notification tones directly from their original location. It’s very susceptible to all kinds of problems, resulting in such a mess as reported in this thread. Custom sounds set up by the user should always be copied by Ambienced to its own folder in built-in storage, and only used from there, so that they are protected against any access problems until the user consciously and intentionally changes them. Or else we’ve got what we’ve got.
Oh, and also some default fallback tones should always be used if there is any kind of problem with a user’s sound, rather than just removing it and allowing it to be replaced with unknown setting carried on from another ambience, which may (and does) cause that e.g. the “No sound” option travels this way from a “night” ambience to the “day” ambience, i.e. where the user definitely does not expect it and relies on properly working notification tones.
2 Likes