element-hq
Very slow notifications when using ntfy due to Element-X seemingly asleep
Steps to reproduce
When using with ntfy for Unified Push notifications send a message to any relevant room that will cause matrix-synapse to issue a notification when Element-X is not currently active (using Unrestricted battery with all Notifications enabled) then just wait (for sometimes minutes).
Outcome
What did you expect?
The notification to occur within a couple of seconds (which all normal "ntfy" notifications are doing).
What happened instead?
It can take from a few seconds to a few minutes for the Element-X Unified Push notification to be announced (unless you "hack" around it).
How did you hack around it?
I duplicated the (postgres) 'pushers' row for the upNNNN changing its 'id' and 'pushkey' it to upNNNNX (then restarted matrix-synapse and manually subscribed to upNNNNX in 'ntfy' on the mobile phone).
Now I get the Element-X notification within two seconds (every time) although of course I also get an ugly upNNNNX notification (and then another one after marking as read).
I can imagine going further to try and work out how to neaten up this ugly hack - but why should it be needed?
Notifications are ESSENTIAL and Element-X with 'ntfy' is just hopeless if you need to hack it like this.
Your phone model
Google Pixel 8.0
Operating system version
Android 15 (Graphene OS 2025050700)
Application version and app store
Element-X 25.04.2 (F-Droid)
Homeserver
(self hosted)
Will you send logs?
No
Are you willing to provide a PR?
No
I am using the same setup in Galaxy S23Ultra.
Never had any issues in notifications. The element-call signalling has a delay about 20s.
Using the extra notification "hack" the call signalling (after I click Join Call from my laptop) also takes no more than 2s (but as you're aware due the RTC Session Error the mobile can't actually do calls that last more than a few seconds typically).
(but as you're aware due the RTC Session Error the mobile can't actually do calls that last more than a few seconds typically).
Not sure I understand this, as I do calls lasting hours...
Also just did a quick test on signalling in mobile internet, it takes around 5-10 seconds before signalling, whilst the element-desktop ringing within 2-3 seconds.
Oh yes - sorry - you has commented in the other Issue (https://github.com/element-hq/element-call/issues/3257) but were not having such problems although I noticed that you stated "Not element-call but widget mode" which I do not quite follow (I am just using Element-X app to try and make calls which for me like the creator of that Issue will not work for generally more than seconds with either a Pixel or iPhone but is working perfectly for hours between laptops).
Oh yes - sorry - you has commented in the other Issue (element-hq/element-call#3257) but were not having such problems although I noticed that you stated "Not element-call but widget mode" which I do not quite follow (I am just using Element-X app to try and make calls which for me like the creator of that Issue will not work for generally more than seconds with either a Pixel or iPhone but is working perfectly for hours between laptops).
You might be using old jitsi-call in element-desktop.
For selfhosted homeservers, you will need to host lk-jwt-service and livekit to make element-call work.
You might be using old jitsi-call in element-desktop.
I am using Livekit - this is a redacted portion of the log relevant to a call that ended with an RTCSession Error:
May 11 09:35:34 host.name livekit-server[1419795]: 2025-05-11T09:35:34.820 INFO livekit.pub rtc/participant.go:1799 mediaTrack published {"room": "!yMgKqTKzKHXDkwvvAd:home.name", "roomID": "RM_Ci63JpPjhq8t", "participant>
May 11 09:35:35 host.name livekit-server[1419795]: 2025-05-11T09:35:35.411 INFO livekit.pub rtc/participant.go:1799 mediaTrack published {"room": "!yMgKqTKzKHXDkwvvAd:host.name", "roomID": "RM_Ci63JpPjhq8t", "participant>
May 11 09:45:26 host.name livekit-server[1419795]: 2025-05-11T09:45:26.280 INFO livekit rtc/participant.go:1036 participant closing {"room": "!yMgKqTKzKHXDkwvvAd:host.name", "roomID": "RM_Ci63JpPjhq8t", "participant": "@>
May 11 09:45:40 host.name livekit-server[1419795]: 2025-05-11T09:45:40.170 INFO livekit rtc/participant.go:1036 participant closing {"room": "!yMgKqTKzKHXDkwvvAd:host.name", "roomID": "RM_Ci63JpPjhq8t", "participant": "@>
In this case I managed to get a Livekit call (between the laptop and Android phone) to last ten minutes (the call was initiated by the laptop).
Regarding the slow notification with "ntfy" I am now using "ntfy" itself to subscribe to the Unified Push (on the same server) and then create another (non-Unified Push) notification so that the Pixel phone will now starting "ringing" within two seconds (still an ugly hack but doesn't show the "gory details" of the Unified Push data now).
Although the slow notification and RTCSession Error are different issues it does make me wonder if they could be in some way be related as seemingly the reason for the RTCSession Error is because of a "delayed event" kicking in (something that perhaps might happen if a thread that should be handling this has "fallen asleep"?).