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.
