Conference duration difference in some participants


We see conference duration time in the conference. But it is different for the first person and the other persons. The other persons see the same time with the second person. I think it is caused from the parameter “if participant_count > 1 then” in the “conference_duration” module. Is that right?

We also sometimes see the fourth participant reset the conference time. After that, subsequent participants will see the same time as these participants. As a result there is some problem in the conference duration. Could you please advice me how to solve the problems. We need to make all participants see the same time.


I just inspected the websocket payload for wss:// and even as the first participant I still get the conference_duration message.

So I don’t think the “if participant_count > 1 then” clause is the issue. That is probably to exclude jicofo focus user which will always be the first in the room.

Not sure what could possibly be wrong in your case. I presume you’re self hosting? Is the server time correct? It’s either that, or room.created_timestamp is somehow being wiped on your deployment and that gets reset when new user joins, or there’s a bug in the handling of that message :man_shrugging:

Can you check if every user is receiving the conference_duration message from xmpp-websocket and if the timestamp is the same?

how can i check if tne client gets the timestamp message correctly?

See my screenshot above. Open js console, load the meeting page. Under network tab, select xmpp-websocket connect and inspect the Messages.

1 Like

thanks for the detailed explanation. actually we see we receive the right timestamps and the Jitsi shows the right time in normal hours. but we start to have problems about that in the busy time.
I understand that Jitsi send new timestamp if it can not create the right timestap because of the below codes.

if room.created_timestamp == nil then
room.created_timestamp = os.time() * 1000; – Lua provides UTC time in seconds, so convert to milliseconds

we noticed that the problem starts at 2 pm and it is still same until we reboot the server. do you have any idea about this problem?

My guess is that your conferences are crashing and are recreated on the fly. The timestamp is set at room creation, and is then sent to the clients as they connect. If a client crashes and reconnect it will receive the same creation timestamp.

If the conference crashes then, it will have a new creation timestamp. But in this case all clients should get a new duration - unless some stay ‘connected’ to the old conference, but then as this conference is not existing anymore on the server, they should really be ‘alone’ and not connected to any other users.

Actually the old participants see the right time and all participants see each other in the same conference. As you said, the conference crashes in terms of the duration but in fact it continues. I think there are different algorithms for the duration and the real conference. First algorithm crashes and the second one continues.

Probably worth figuring out why/if prosody crashes since it is likely conference duration would be just one of many things that could go wrong if it is the case.

How about enabling debug logging in prosody then take a look next time things go screwy?

Interesting. This could mean that users are reconnecting to the same conference, but in this case they are not getting the creation timestamp, but are taking the current date/time.
Smells like a hideous bug if it can be confirmed, definitely to be investigated.
What is in Jicofo logs ? AFAIK room creation is not logged explicitly in Prosody, but in Jicofo logs room creation is logged.

actually we realized that there is the problem between 2 and 5 pm. after 5 pm it is solved itself by no touching. no need to restart or reboot.
by the way i am tryin to collect logs tomorrow.