Delayed notification with UnifiedPush and ntfy on /e/OS

[muellerto]

Bug description

I uninstalled my long used Molly-Unified Push and changed to the ordinary Molly-FOSS now, still using Unified Push via ntfy.

I have the impression that the current Molly-FOSS (7.26.1-1-FOSS) does often (but not always) not play the configured notification sound until I manually wake up the screen for another reason. When I do this it can happen that I suddenly get two or three beeps for received posts which are already older than an hour.

Am I the only one with that phenomenon?

The accu optimization is of course switched off, so it should always run.

[valldrac]

Can you try something? Switch to WebSocket in Molly's notifications settings for a few days and let us know if you notice any difference.

It would be helpful too if you could attach the debug log and note the date and time when a notification was missing.

[muellerto]

I found another thing, some minutes ago: I have an option in my global Settings app, under System | UnifiedPush. (I've never seen that section, is it new?) There's a single option called "Enable the distributor", this was off if my case. The subtext under this option explains that the option "enables 3rd party apps to receive push notifications". Not sure if Molly depends on this. I switched it on now. I'll report if this had any impact.

I'm still not sure about my configuration of ntfy. I had a Molly-related entry from my old Molly-Unified Push. I didn't remove or change this old entry, it's exactly the same which worked for a year. Can I still use it? Or should I make a new one now?

[p1gp1g]

I found another thing, some minutes ago: I have an option in my global Settings app, under System | UnifiedPush. (I've never seen that section, is it new?) There's a single option called "Enable the distributor", this was off if my case. The subtext under this option explains that the option "enables 3rd party apps to receive push notifications". Not sure if Molly depends on this. I switched it on now. I'll report if this had any impact.

I think you are using /e/OS, they add a distributor by default in their system apps since v2.5, and this setting enable it.

I'm still not sure about my configuration of ntfy. I had a Molly-related entry from my old Molly-Unified Push. I didn't remove or change this old entry, it's exactly the same which worked for a year. Can I still use it? Or should I make a new one now?

I'm pretty sure you are using MollySocket in airgapped mode, isn't it ? This is the reason MollySocket is designed to work with the webserver, you don't have to think about all of this. If you still want to use with airgapped mode, copy again the parameters and add it again to your server

[muellerto]

I found another thing, some minutes ago: I have an option in my global Settings app, under System | UnifiedPush. (I've never seen that section, is it new?) There's a single option called "Enable the distributor", this was off if my case. The subtext under this option explains that the option "enables 3rd party apps to receive push notifications". Not sure if Molly depends on this. I switched it on now. I'll report if this had any impact.

I think you are using /e/OS

Yes :)

I'm still not sure about my configuration of ntfy. I had a Molly-related entry from my old Molly-Unified Push. I didn't remove or change this old entry, it's exactly the same which worked for a year. Can I still use it? Or should I make a new one now?

I'm pretty sure you are using MollySocket in airgapped mode, isn't it ?

I scanned this QR-Code: https://molly.adminforge.de This is not the airgapped mode.

[p1gp1g]

Ok, then you don't have to care about entries and endpoints. If you want you can unregister the old molly-up on ntfy, it doesn't implement cleanup yet if I recall correctly

[DeadSecTr]

I found another thing, some minutes ago: I have an option in my global Settings app, under System | UnifiedPush. (I've never seen that section, is it new?) There's a single option called "Enable the distributor", this was off if my case. The subtext under this option explains that the option "enables 3rd party apps to receive push notifications". Not sure if Molly depends on this. I switched it on now. I'll report if this had any impact.

I think you are using /e/OS

Yes :)

I'm still not sure about my configuration of ntfy. I had a Molly-related entry from my old Molly-Unified Push. I didn't remove or change this old entry, it's exactly the same which worked for a year. Can I still use it? Or should I make a new one now?

I'm pretty sure you are using MollySocket in airgapped mode, isn't it ?

I scanned this QR-Code: https://molly.adminforge.de This is not the airgapped mode.

Whats your config in ntfy app?

I use also adminforge with Molly Foss (Unified Push) and it works very well.

My settings in ntfy app:

[farfalleflickan]

I'm running mollysocket airgapped with ntfy and recently switched from Molly-UP (which was working flawlessly) and
I think I might be having the same issue on Graphene - often I won't get notifications until I open Molly, almost like the app isn't actually running in the background (all optimizations are disabled so I'm pretty sure it's not that...).

I've tried randomly pinging my device from mollysocket and I always get those notifications.

[muellerto]

The situation is now as follows:

I checked this about this new /e/OS option and it seems to be a new feature I didn't notice until now: they integrated ntfy into the OS (they made a fork as they always do). This new builtin service has even still the same name "ntfy" which is not helpful at all because you see always two ntfy in lists and do not know which one is which. More info about this all here and here.

What I read is: on /e/OS you don't need an own ntfy anymore. The one from the OS will do the job when you switch it on.

So I did indeed uninstall my own ntfy (long ago installed from F-Droid) to get clear. And I set Molly to the remaining ntfy which is the one from /e/OS. Since yesterday I got several messages ordinary with a proper beep in the right moment. But I can't tell until now if this also solves the problem I had. Need two days to check this.

[DeadSecTr]

Have you deactivated "battery optimizations" for Molly?

[muellerto]

Have you deactivated "battery optimizations" for Molly?

Sure, see my first post above.

[valldrac]

I'm running mollysocket airgapped with ntfy and recently switched from Molly-UP (which was working flawlessly) and
I think I might be having the same issue on Graphene - often I won't get notifications until I open Molly, almost like the app isn't actually running in the background (all optimizations are disabled so I'm pretty sure it's not that...).

In Molly-UP, the app could switch back to using WebSocket silently, without notifying the user, especially for those using airgapped mode. Could it be that Molly-UP was running on WebSocket, but now Molly works with UP, raising a latent issue with ntfy and Graphene?

Actually, with UP enabled, Molly shouldn't stay in the background. The responsibility for push notifications transitions primarily to the ntfy app, which must stay active and responsive in the background. From your description "notifications only arrive after opening Molly" might indicate that ntfy (not Molly) is being terminated or restricted, leading to the issue.

[farfalleflickan]

I'm running mollysocket airgapped with ntfy and recently switched from Molly-UP (which was working flawlessly) and
I think I might be having the same issue on Graphene - often I won't get notifications until I open Molly, almost like the app isn't actually running in the background (all optimizations are disabled so I'm pretty sure it's not that...).

In Molly-UP, the app could switch back to using WebSocket silently, without notifying the user, especially for those using airgapped mode. Could it be that Molly-UP was running on WebSocket, but now Molly works with UP, raising a latent issue with ntfy and Graphene?

Actually, with UP enabled, Molly shouldn't stay in the background. The responsibility for push notifications transitions primarily to the ntfy app, which must stay active and responsive in the background. From your description "notifications only arrive after opening Molly" might indicate that ntfy (not Molly) is being terminated or restricted, leading to the issue.

Interesting. Unfortunately I don't have logs to compare to Molly-UP, but I feel like I would have noticed the battery drain (the whole reason I switched to UP was because of WS murdering my battery) if that was the case. Regardless, I haven't had battery optimization on for either ntfy or molly and ntfy has been running fine with my tests (send a curl ping every hour to a topic).

I will try to mess around some more and see, but given that the only things that changed was that I updated mollysocket and switched from Molly-UP, I am inclined to blame one of them.

[muellerto]

After more than a day now I must say it works as expected. I made a lot of postings to my device using a second device and it's interesting: it takes sometimes a second and sometimes a minute, but the beep comes also when the device is sleeping. Good so.

Nevertheless there's a gap between the blinking LED (which is always some seconds faster) and the beep. Don't know why. It takes just two different ways.

After all my conclusion is: the problem was probably my ntfy, it's old Molly entry and/or it's coexistence with the /e/OS integrated ntfy. After I uninstalled it and switched my Molly to the /e/OS integrated ntfy it works as expected (on two devices).

If no one else has this problem we could close here.

[shortwavesurfer2009]

Something still seems wrong. I had to switch from Molly UP to regular Molly. And for whatever reason now, notifications do not always seem to show up. I do have ntfy installed but never set up molly to work with it so it has no entry in ntfy. Since I'm getting delays receiving notifications, I went into the Molly settings and tapped notifications, and instead of bringing up the notifications options, my app hangs, and eventually, Android tells me that it's not responding and asks me to close or wait.

[muellerto]

In this case I suggest to clear all the app data storage and it's cache. And then do a reboot to restart Molly indeed new. Then it runs like fresh installed, this means it should again be on WebSocket notification. You should then do the switch to UP as the first action. There's then a section of options called "Configure Unified Push". The Distributor should be "ntfy" by itself and there shouldn't be any other "ntfy" in the list. With this settings the "Test configuration" item should work.

[valldrac]

I went into the Molly settings and tapped notifications, and instead of bringing up the notifications options, my app hangs, and eventually, Android tells me that it's not responding and asks me to close or wait.

That's a bug we haven't seen before. We need your debug log to fix it. After the app crashes, restart it and go to Settings > Help > Debug log. Send the log to [email protected] with a reference to this ticket. Thanks!

[shortwavesurfer2009]

Debug log gives me nothing but this.

[shortwavesurfer2009]

Never mind, it appears as though my phone really needed a reboot.