I’ll regenerate a version this week with a lot of changes, but invalid decryption generally come from two different gnutls version. But it’s not the case there as you say you’re using 2 Ubuntu 22.04 with the same snap version
1 Like
Excellent! I’ll look forward to testing it! And yes, all of my desktops are running the same Ubuntu 22.04 LTS distro. The only interesting difference is that the test machine that fails with consistency is on the wifi of my switch router while everything else is on the e-net switch. Same subnet of course. Other apps (Tox, wickr, ssh, etc) work fine on that machine. Jami on the android tablet, also on the same wifi works fine. I did check and all gnutls packages on both test machines are at the identical versions.
1 Like
I too am looking forward to your new version. The dropped connection problem occurs with both my Android and Linux devices intermittently. It seems to be related to the devices going to sleep and waking up unable to re-connect. Each time it has been solved by simply switching the account off-line and back on-line again. I’ve been reading the logs, but so far have not deduced the cause.
1 Like
I got it working on Android and Debian, but not on Arch Linux.
I don’t see why they don’t just make an official flatpak so ALL Linux users can easily use it.
2 Likes
It is almost as if the programmers created the GUI as an afterthought.
More likely - MUCH more likely - it started as a “desktop” application and was then “ported” to a phone. But I don’t happen to know that. It’s just a very common issue.
1 Like
I have to wonder if at least some of the message transport issues are an aspect of user expectations.
Notably, because of the secure nature of Jami, with no vendor, like your cell phone provider, to take a message and hold it ready to deliver for you sometime later, BOTH systems must be up and connected via Jami for the message delivery mechanism(s) to work.
This may not be clear to all users!
As for the GUI, I’m a real veteran of computers and I found a few things annoying and a few things lacking.
Perhaps the most annoying thing is how on my particular phone hardware the DONATE image blocks use of some of the options that are lower on the list, and this is even with the option to hide donate reminders (or however it’s phrased) selected. One easy solution would be to make the list longer by a little so the user can scroll so the option button(s) become visible above the Donate icon.
What’s missing is a sound option for speaker vs built-in microphone vs headphones. … At least it should have a speaker phone option, and non-speaker or headphones choice can be made by plugging in or unplugging in a headset.
…I’ll go make that recommendation!
2 Likes
This thread is getting a tad off topic. With all due respect to the contributors, the most serious issue I (and the OP) see with Jami is that it does not fulfill it’s core mission: allowing two devices to communicate reliably. I currently have two Ubuntu desktops that are literally in the same room, on the same subnet, that exhibit easily reproduced failure characteristics (described above). I have various other devices that communicate very reliably with each other so why these two are problematic is a puzzle.
I have confidence that the dev team is looking at this although perhaps not with the aggressiveness that this problem deserves. Not being part of the team I have no idea what the end goal for this project is. As an outsider it appears that Jami is a project that seeks to improve on the capabilities of Tox, which is a similar, legacy app that has been languishing since no one seems to be actively maintaining it. The gold standard in this space would be Slack although slack is not at all private or anonymous.
Currently, Jami lacks some of the important, basic features of Tox. A plus would be if Jami is actually able to deliver messages to devices that are offline, something that Tox cannot do (but Slack does). If you close out a Tox session before a message has been delivered the message is lost forever.
Speaker/headphone support? Please. IMHO, job one is to address the OP’s problem!
1 Like
Yes, the topic is reliable connectivity. I’m just wondering if the non-intuitive nature of the GU is causing some of us to push the wrong buttons.
I would like the exact procedure to be clearly defined so that i can read it and then know if I am doing it correctly. I am using Debian 11 and Xfce 4.16.
I very much agree with your assessment. 
When I first looked at Jami I found the GUI to be VERY confusing and the user level documentation lacking. However, the detailed documentation on the Jami architecture is first class. Being a seasoned systems engineer I was able to figure it out. And as near as I can tell, it’s pretty difficult to arrange the settings where the app just doesn’t work. Even between devices where the connectivity is working the communications seem flaky and unstable. The two desktops that currently won’t talk to each other seem to be failing due to a TLS/encryption issue. Coding in better failure reporting to syslog might help ID problem sources quicker. Ubuntu 22.04.03 LTS here.
UPDATE: This core problem appears to be very serious and with all due respect, prompts to donate seem premature and presumptuous to me. I just tried to connect to someone on an Android device and am getting that same annoying problem: stalled… “Downloading the conversion” on his end he says. To be kind, Jami sadly has a ways to go before it is ready for prime time. I think this app has a lot of promise but the dev team needs to kick it into second gear getting basic functionality to work outside their own test environment.
Log for failure:
[1703627234.957|52836] [device e3d67bbaee01a5d7dce4fd6cb6f0fd5f4212b00ca9010ba891798872cb6ee1d8] Answer to connection request: put encrypted ok
[1703627235.194|54933] [ice:0x7fea78429540] TCP negotiation success
[1703627235.194|54933] [ice:0x7fea78429540] TCP connection pairs ([comp id] local [type] ↔ remote [type]):
[2] 144.217.83.140:23291 [relay] ↔ 208.71.200.97:50129 [prflx]
[1703627235.194|52790] [device e3d67bbaee01a5d7dce4fd6cb6f0fd5f4212b00ca9010ba891798872cb6ee1d8] Start TLS session - Initied by DHT request. vid: 4138952422278540
[1703627235.194|54934] [TLS] Start client session
[1703627235.203|54934] [TLS] User identity loaded
[1703627235.203|54934] [TLS] handshake
[1703627259.195|54934] [TLS] handshake failed: Error in the push function.
[1703627259.195|54934] [device e3d67bbaee01a5d7dce4fd6cb6f0fd5f4212b00ca9010ba891798872cb6ee1d8] TLS connection failure - Initied by DHT request. channel: - vid: 4138952422278540
1 Like
Hello, this is my first post in this forum. I introduce myself: Gnu/PureOS and Gnu/Guix User, a happy Librem 5 owner, and a medical doctor.
as @ECaptainRaj mentioned, is required toggling Offline/Online on both devices before you want to connect and periodically (every 20 minutes). I just stablished communication and was able to send a 98mb video file between Android 12 phone and Gnu/PureOS Desktop.
I was using 4G connectivity on Android and Internet via LAN cable on Gnu/PureOS Laptop.
All in less than 20 minutes margins. I don’t know if the connection get interrupted beyond that time or if still can happens using Jami actively.
The Download part has no option to select where to Download the file.
You can select Open location from three vertical dots menu.
In my case default download folder is:
/home/username/.local/share/jami/3025de46285adc09/conversation_data/fb8aceee9d98e81ca4a1e727a35f09cbdafc0562
The last 40 alfanumeric sequence correspond to the sender account.
1 Like
Be careful with the flatpak version. For some reason notifications do not work. In fact, I have uninstalled the flatpak version, but have continuing log messages from D-Bus:
connector ‘dbus’ not found
D-Spy reveals:
unix:path=/run/flatpak/bus
This is a legacy of the flatpak install.
If anyone knows how to correct this, I would appreciate some guidance.
What were the conclusions of sharing your logs? Have the developers been able to spot the origin of this problem?
1 Like
Sorry to say, nothing came of it. Except fr a recent post by someone in the dev team the project seems to be languishing. Have not seen any updates since I started testing Jami
1 Like
I have a PC (running Trisquel) permanently on, it has a camera and microphone, a Jami account is configued with automatic response to calls. When I call the account on this PC (from another PC running Trisquel mostly, rarely from Android), it always works. This is at least one scenario where I can say that Jami is 100% reliable.
2 Likes
I have been testing Jami between a Linux computer and Android phone. Since the recent updates (Version: 202401241333 on Fedora and version 20240118-01 on Android,) Jami has performed very well without the intermittent loss of connection that had previously plagued me and other users. Praise to the developers working on this!
3 Likes
20231128.0 is the latest version available on the Ubuntu platform snap store. That version has been very problematic.
I had problems with a prior version from flathub. After un-installing and re-installing from the Jami repository, everything worked fine. It seems that Linux package management is getting better, but confusion remains.
1 Like
Avron, this is a very interesting use of Jami. How did you configure for automatic response to a video call? I’ve looked at the message auto-responder extension, but it doesn’t seem to accommodate video calls. It would be cool to use an old android phone to monitor my greenhouse.
1 Like
Hello @Easyrider
Are you still experiencing issues on Ubuntu? 
We released a new version! I also use Jami on Ubuntu, Windows (on another PC) and iOS.
@Iacobus
To configure automatic responses to a video call:
1) Once you log in, click on Open settings
2) In the Account section, click on Call settings
3) Turn on Automatically answer calls
Cheers,
Loïc,
Jami’s community manager.
1 Like
Hello @tonypl5 
Let us know if you still experience the same issues with Jami’s new version?
To select where files are being downloaded:
1) Once you log in, click on Open settings
2) In the General section, head to System
3) Set up Choose download directory
Also, the last 40 alphanumeric sequence is the conversation ID, not the sender account.
Cheers,
Loïc,
Jami’s Community Manager.