Definitely: I get no beep when Molly receives a new message.
This came with /e/ 3.3-t on my FP3, under 3.2-t it did still work correctly.
Receiving generally works, also in time, no delay, the notification appears also in the notification area, the LED blinks, but I can’t hear any beep anymore. I configured another beep, I checked other settings, all as it should be.
Interesting is: it’s only Molly. Other apps (mail, SMS, alarm clock) do beep.
Another thing is: sending a test message from Molly to myself does also not work anymore. This is a Molly feature to check if Unified Push works. And this feature did work about a year ago, I used it several times. Now nothing happens.
Before I open a case in the Molly repo … has anyone also seen this?
Unified push or the app which is part of the OS had some changes. It is automatically activated now. Since then couple users have reported to be a problem receiving messages, me included. Someone in the feedback for 3.3 suggested to activate some notifivation of ntfy (system app) but that didn’t work for me I think for @obacht it did.
Checking service within Molly also gives me no message (there is now an option to activate FCM Google Play Services ).
Anyhow, since I am used to checking the app because I close it often with too many swipes, nothing changes for me.
I’m on sunfish 3.3 A15 and for the last week or so the integrated ntfy/UP seems to be stable.
Currently no second ntfy install on my device.
I get beeps for incoming molly- messages.
UP test within molly works ok (test message + beep received)
UP test via UP-example ok as well.
For me the above works/worked w or w/o activating “abo services” in integrated ntfy notification settings.
Yet still there are some glitches as I sometimes miss signal-calls for there’ s no notification nor beep but I get one saying “missed call”
As long as function of eOS-integrated ntfy/UP is obviously device-dependent (least from what I read in the forum and gitlab) and there’s no proper doc on eOS-UP-implementation I tend to put the blame on eOS instead of Molly.
I agree, fcm-option seems odd as molly states otherwise for FOSS-version. But I would not choose that anyways and would not mind as long as the foss version keeps open maps instead of G.
Until last week I could not receine calls properly, I thought I must have something I am the culprit of and in the end I found by comparing a fresh install on a test device that I changed ‘calls not direct’ which should hide IP-address (data privacy → additional settings).
I agree, as long as it doesn’t connect anything without choosing it, I am good with it. But yeah, odd that it is in the FOSS app which should ony use FOSS…
Ha, I switched this mysterious “Abo Service” option (what is this???) on. And now (one hour later) I got a message AND a beep. Should this be the solution???
My current interptetation (w/o further insight) is that abo services handles everything but murenas own notifications (*), so this might well be it… But we are still waiting for documentation.
(*) my assumption because notifications of whatever apps are handled as “subscribtions” within ntfy…
Yes there are still flaws in UP-implementation or server-issues or hell knows what… since early this week molly-notifications come with a significant delay or only if I open the app (despite test-notifications within molly or with UP-example pop up immediately…)
This delay seems to be something else because also mail and SMS notification beeps are affected. I made already a case for that. This problem exists already for years but we saw a period in the past where it didn’t come up very often. Now (since 3.3) I have it every few days.
It gets worse and worse. Yesterday I got a Signal call. – I didn’t hear it! Now it gets interesting: a telephone that doesn’t ring.
We checked this by experiment in the evening. Signal calls are indeed absolutely quite, normal calls via mobile network are working correctly. But now I have to tell people “Don’t call me on Signal. I can’t hear it.”
A workaround seems to be not to use Unified Push. When you change to WebSockets it works immediately as expected.
Would be interesting if the external ntfy app could also bring an improvement …
Update: no, the externally installed ntfy app (from F-Droid) seems not to be a usable alternative. I guess it conflicts again with the internal one which has the same name and which is somehow “uncontrollable”.
Update to the Update: I installed now the app Sunup (from F-Droid) for testing which claims himself to be a “UnifiedPush distributor using Mozilla’s push server.” as a replacement for any internal or external ntfy. Works great at the first attempt. And there’s no danger of confusion with the internal ntfy service, you can just let it as is.
thanks for the recommendation, I´ll give it a try.
I observed that in order to generally not miss incoming calls, Molly must be active in the background (in terms of not being fully shut down by swiping it off the list of recently used apps, not sure about the correct term…I have a habit of shuting down my apps but learned to exclude molly from that routine), same same for ntfy or sunup
update: I found a setting in notifications settings of signal/molly to allow receiving notifications whilst the app is closed … now I receive incoming calls even when app is not active in the background … that´s a huge improvement for me.
