I used to run older versions of Jami when newer ones were flaky. I found it frustrating that I’d have to experiment with downgrading to one or two or three older iterations sometimes in order to find one that seemed to be more stable.
There needs to be a stable/release version which, even if it didn’t change for 6 months or a year even, at least it would (or should) work reliably for that time till the next thoroughly tested one is ready.
Still, I would hope that there might be emergency patches from time to time with bare minimum changes if that is absolutely necessary, but I like many, ALWAYS, ALWAYS, ALWAYS will preference stability over features, especially when it doesn’t or hardly works at all sometimes!
But after all, how authors imagined adding account to smartphone from main account running on desktop with no camera? Smartphone says - here is your QR code, scan it with.. what?
As an option desktop instance says - “you can use auth code instead”, but what is that “auth code” is probably top secret info.
Really, chasing new trendy features and not testing basic ones is not good way to my understanding.
And again, only devices in the same LAN work ok with each other. Different city, country - it is very random.
Sorry for long delay. It took a lot of time to convince some of my contacts to try Jami again.
People in Japan refused to retry completely.
Some people in Russia agreed.
Scene: Latest flatpak release of Jami on Linux, Latest Windows version donwloaded directly from Jami. No mobiles involved in test.
Result 1: First “hello” and first audio/video call was ok. All subsequent - failed. I have 6 jami DHT servers ans 6 TURN around the world. Tried all of them. Result is the same. First video session ok, all subsequent - cannot find contact, it is orange in the contact list.
Result2: After “very latest” flatpak version for Linux installed - Linux people cannot even start it, Jami crashes with:
Dec 05 22:13:12 z87n net.jami.Jami.desktop[15015]: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Dec 05 22:13:12 z87n net.jami.Jami.desktop[15015]: Available platform plugins are: linuxfb, wayland, eglfs, minimalegl, vnc, xcb, minimal, offscreen, wayland-egl, vkkhrdisplay.
Dec 05 22:13:12 z87n systemd-coredump[15018]: Process 15015 (jami) of user 1000 terminated abnormally with signal 6/ABRT, processing…
Dec 05 22:13:12 z87n systemd[1]: Started Process Core Dump (PID 15018/UID 0).
Dec 05 22:13:12 z87n systemd-coredump[15019]: [🡕] Process 15015 (jami) of user 1000 dumped core.
Stack trace of thread 2:
#0 0x00007ed033433344 n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x9a344)
#1 0x00007ed0333da50e n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x4150e)
#2 0x00007ed0333c1882 n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x28882)
#3 0x00007ed03527a25b n/a (/usr/lib/x86_64-linux-gnu/libQt6Core.so.6.8.3 + 0xc825b)
#4 0x00007ed0352c93f9 n/a (/usr/lib/x86_64-linux-gnu/libQt6Core.so.6.8.3 + 0x1173f9)
#5 0x00007ed03527b851 n/a (/usr/lib/x86_64-linux-gnu/libQt6Core.so.6.8.3 + 0xc9851)
#6 0x00007ed035acf380 n/a (/usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.8.3 + 0x140380)
#7 0x00007ed035b80fb8 n/a (/usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.8.3 + 0x1f1fb8)
#8 0x00007ed035b81a50 n/a (/usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.8.3 + 0x1f2a50)
#9 0x00007ed035357345 n/a (/usr/lib/x86_64-linux-gnu/libQt6Core.so.6.8.3 + 0x1a5345)
#10 0x00007ed035b855bd n/a (/usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.8.3 + 0x1f65bd)
#11 0x00007ed036517c45 n/a (/usr/lib/x86_64-linux-gnu/libQt6Widgets.so.6.8.3 + 0x1a6c45)
#12 0x00005cae1a08ec99 n/a (/app/bin/jami + 0x363c99)
#13 0x00005cae19fe0b75 n/a (/app/bin/jami + 0x2b5b75)
#14 0x00007ed0333c33c8 n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x2a3c8)
#15 0x00007ed0333c348b n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x2a48b)
#16 0x00005cae19ffe775 n/a (/app/bin/jami + 0x2d3775)
ELF object binary architecture: AMD x86-64
Dec 05 22:13:12 z87n systemd[1]: systemd-coredump@1-4097-15018_15318-0.service: Deactivated successfully.
Sorry again, after a year Jami is still not useable at all in my environment.
P.S. Testing in the same LAN is always ok, despite of OS: Windows, Linux, Android, all good. But this is lab test, not real life.
Wow, you actually have your own DHT server. Could you share its address so it can be used when the default bootstrap nodes aren’t working? Back to the main point, do those devices have IPv6 addresses? Poor network conditions usually mean fairly long connection wait times.
Not sure if it is good idea to share them publicly.
However I have contacted Jami on 19th of November and submitted my DHT nodes so they could add them to public network. Nevertheless no reply received still.
Maybe I can share them prvitaly - please drop me a line.
Yes, 5 of them are dual stack IPv4+v6.
Yes, I tried default DHT bootstrap node and default TURN server - result is the same.
I have now removed Flatpak version of Jami and installed from repository (Arch, using pacman). No changes, result is the same. Not crashing though, however 2 new issues appeared: a) app cannot be reinstated from running in background, it just starts second copy which says “no networking connection”, b) now I even cannot do the chat with myself (that option I used before to keep notes for myself by creating a chat with myself). Mobile Jami is ok in this kind of chat, desktop linux from Arch repo says “This conversation has ended”, it can see new messages written on mobile, but cannot reply, no such field. Also this desktop version doesn’t see profile changes made on mobile (avatar change, display name change, etc).
So, at this stage I cannot find a way to keep basic functions, even some text chats.
Hello @ovari ,
After numerous tests I’ve found following things:
All my DHT nodes are ok, despite of geo-location, Jami clients can work properly with them.
TURN server not only required for audio/video, but also is vital for normal p2p connections (to see one is online, to send chat messages, etc). That was unclear for me before.
2 of 4 my TURN servers were configured improperly for Jami.
I run “coturn” there, and widely advised in Internet parameter “no-tcp-relay”, which was intended to reduce latency breaks Jami client functions and it even crashes. Removing that parameter fixes the issue. I’ve posted my experience in related issue here: Making sure you're not a bot! Also one my TURN server is either heavily blocked by local “regulator” or has some networking issues as the same version of coturn on the same version of OS but in different continent works ok.
At the moment having latest Flatpak, latest Windows Jami client and latest Android one works ok at least for 1-to-1 chat/audio/video.
Planning to test group calls in close future.
Thank you for patience and sorry for my impatience
Hi, I also tried running it in Russia, but the initial messages and calls only went through on the same Wi-Fi network, but then there was silence. I tried connecting two devices via VPN, but the result was the same: no calls or messages. Is there any way to change this, like setting up a proxy or something? Thanks.
I agree, I tried using jami for several years and in my opinion a couple of years ago it was more stable and it was difficult but possible to use, now it is completely impossible
Hi and thanks for the info. I’ve always had Jami installed on my device via Fdroid and NTFY enabled. I’ve also just done this for another device that has Google services, but that’s not the issue. Both devices are connected, either on the same or different ones, and the online status is showing, QR codes have been scanned, contact has been confirmed, but both have a yellow status. No matter what I send from one device or the other, nothing comes through, including calls; everything is just dead. Here’s the log and a screenshot. It also doesn’t matter whether the VPN is enabled on both devices, on one, or completely disabled on all.
