Huge battery drain when using Jami [blocked by pupnp upstream]

I'm losing about 2% battery a minute on my iPhone 5s. Can this be improved?

changed title from Hue battery drain when using Jami to Huge battery drain when using Jami

changed the description

Only with the app open?

Yes. When the app is not being used (running in background) the battery is OK. I assume this points to a client issue rather than daemon.

The daemon isn't running when you close the app (except for wakeups you receive a push notification from the DHTproxy), so it could still be the daemon. They pushed a new version to the app store a few days ago, by the way.

assigned to @kkostiuk

will investigate

changed milestone to %Backlog

removed milestone

added SprintTo review ~21 + 1 deleted label

Ok so it seems this is not related to Jami directly but PUPnP (a contrib).

PUPnP seems affected since 1.14.0 due to https://github.com/pupnp/pupnp/blob/master/ChangeLog#L175 (https://github.com/pupnp/pupnp/commit/a3912b04653cdefd6f7b627d73eef6f234a9882c) because SO_REUSEADDR is handled a bit differently on Apple devices than other platforms.

A bug is opened upstream (https://github.com/pupnp/pupnp/issues/328). For Jami we just disabled the reuseaddr feature (https://review.jami.net/c/ring-daemon/+/18178). A testflight version is currently generated and should decrease the battery usage.

Best regards, Sébastien

mentioned in commit 7033794d

just a quick note to say I got out my iPhone 5S and ran the Jami update. Left it on battery overnight, I believe it is still hammering the battery. I will ask my brother if he can reinstall Jami and try

on testflight? The fix is only on testflight for now I think

Version available in the App Store now, has a fix for the battery usage when the app is in the background. Now, with new jami update it still hammering the battery? Could you check it in iPhone battery usage statistic?

Thanks, I'll try over the weekend as well as ask another to try

Sadly we didn't even get to trying the battery. We sent a few messages and fell fowl of the "unjoinable peer" - Sadly my final buddy will no longer be using Jami.

I wish the project and developers all the best in the future. My advise is go back to the beginning and rethink how the infrastructure works, use XMPP with OMEMO (or your own) encryption? As you may know XMPP can potentially handle voice, video, file transfer, and messaging. These are all reliable tried and tested with thousands of servers around the world that are used for other messaging platforms and some enforcement services so the chances of it being shut down are minimal. It would be good to rewrite Jami with XMPP and all the encryption installed and preconfigured as part of the build. To the user all they do is install and use. The XMPP registration could be anonymous in the form of a public key as now for privacy. E2EE between the clients as standard.

There's already a messenger that uses XMPP (and P2P): Twinme. It does have a better connection stability but the video quality of Jami is better. Link: https://twin.me/en/support/technology-behind-twinme/ ,https://twin.me/en/support/twinme-use-servers-data-stored/ & https://twin.me/en/support/twinme-protect-data/

https://github.com/pupnp/pupnp/issues/328 for the rest of the discussion

I leave till this is opened

changed milestone to %Backlog