According to Android SDK · Jitsi Meet Handbook the activity should finish when the meeting manager ends the meeting for participants. This was happening on 3.10.2 but fails on 4.1.0
This class encapsulates a high level API in the form of an Android FragmentActivity which displays a single JitsiMeetView . You can pass a URL as a ACTION_VIEW on the Intent when starting it and it will join the conference, and will be automatically terminated (finish() will be called on the activity) when the conference ends or fails.
Is there possibly any incompatibility with the jitsi server version we are using?
hi jitsi-meet-prosody 1.0.5638-1 all Prosody configuration for Jitsi Meet
hi jitsi-meet-web-config 1.0.5638-1 all Configuration for web serving of Jitsi Meet
hi jitsi-videobridge2 2.1-592-g1e2879e0-1 all WebRTC compatible Selective Forwarding Unit (SFU)
They seem to all have various version numbering and updates are released at different times (which I completely understand). I just don’t know if it’s definitely client-side? I figure it is since I do get the BroadcastEvent but just wanted to be thorough.
So I used meet.jit.si and it worked as expected. It must be something server side I guess. Please see my previous post about the server versions we’re currently using. And I apologize for consuming your time when it seems to be a deployment issue on our end.
I took a look at the logcat and TBH I’m a bit lost. The SDK bundles all code, so it should always work with the backend.
Unfortunately I cannot dig deeper, your backend is ~1 year old (Release jitsi-meet_5638 · jitsi/jitsi-meet · GitHub) and since it’s fixed in further releases I cannot justify the time to dig into it. Plus, even if we found the issue, we don’t make old re-releases.
So, the best you can do is update the infra. Sorry about that.
I completely understand and I didn’t expect any solution once I realized it works with your latest infrastructure. Unfortunately I don’t control the back end in this environment. Thank you for your time.
No, you’re confusing the version of the wrapper (Jitsi meet) with the versions of the individual packages. JM 2.0.5638 is the wrapper, the individual packages have their own version numbers (e.g. jitsi-meet-web 1.0.5638). All those packages are bundled in a wrapper which has its own version number.
Going by this, you are running version 6689 of jitsi meet (the bundle). The individual packages in those bundles have different version numbers. The bundle wraps them all and presents them as one installable package.
The changelog.txt also has its own version number… lol.
I get the bundle concept. With all the version numbers (meta package vs individual packages) and various ways to install / upgrade, it’s confusing (to me anyway) how to help someone if there is no direct way to know exactly how current things are. I have always used dpkg -l
I think it just takes getting used to. Yes, it would be more coherent if everything had the same version number, but because they’re different packages, each one needs to be versioned differently. dpkg -l will return all the relevant packages with their corresponding version numbers. But for more robust reporting, I use: