the timer is keeping the previous sessions, including different conferences #14815
Comments
|
What is the jitsi-meet that is installed? What is the OS version? What is the prosody version running on the server? |
|
debian 11.9 #apt list --installed | grep jitsi |
|
|
|
ii jitsi-meet-prosody 1.0.7952-1 all Prosody configuration for Jitsi Meet |
Check prosody logs when you are closing conference1 and when opening conference2? What do you see? Can you share it here? |
|
here is my new test. opening new room /conference1 timer started to 00:00 and do not start ! 00:00 remains. no idea about what's going on here. |
|
Having exactly this same issue. The timer first was not starting at zero and now it is stuck at 0 and does not count. Ubuntu 22.04.4 apt list --installed |grep jitsi jitsi-meet-prosody/stable,now 1.0.7952-1 all [installed,automatic] dpkg -l |grep prosody ii jitsi-meet-prosody 1.0.7952-1 all Prosody configuration for Jitsi Meet |
|
Timer started again with new conference 2 days ago, and re-openinng same conference link today, the timer kept the previous session from 2 days ago. |
|
Do you have the log in prosody that the meeting ended two days ago? |
|
my mistake. this is not even the same conference. 2 days ago I opened a conference /mrcc. I closed it Today I opened a new one on different url (/testatoto) I re open it, and then timer gone to 0 How does work this timer ?! I cannot figure out the way to make it work properly. Can't we have a command / button to force to reset it ? maybe this would help |
|
When the first participant joins we record the time when the meeting was started: When the last person leaves the room, the room is destroyed and this value disappears. No idea how this is possible at all. How are you opening the meeting where you see the wrong timer, is that web, or is that mobile? |
|
always web. |
|
I have noticed that the timer value depends entirely on the time of day. Sometimes it will not increment at all staying at 0. Other times, like currently at ~17:20 AEST it has begun to increment but will not stop if meeting is ended, persists and is identical across every meeting regardless of room name. |
|
Is your server setup to use UTC time? |
|
I have changed it back and forth and it made no difference. |
|
UTC by default |
|
Not sure if this is an issue but I always kept my config from previous versions of jitsi. Problem only started after an upgrade of jitsi, which required a php update and ubuntu release upgrade. Not sure if this only applies to the SIP trunk though. |
It is both for me |
|
We have the same problem in our setup. We have been experiencing this issue since the update from version It may be of intereset that we use the lobby feature and implement authentication via JWT (including token_lobby_bypass). Since @damencho mentioned the connection with |
|
@virtuaris if you are reproducing the issue, can you comment and see is it reproducible like that? |
|
In the previous session, the timer remained at 00:00. After commenting out the component and restarting Prosody, the timer starts in a new session at the time of the duration of the previous session and continues to count up. |
And that is when using web? |
Yes. Sorry for not mentioning that. We use Jitsi in web-context only. |
|
You can try debugging it, adding a print here: which room and the value it adds. Same here: and put a print the int else if for some reason it was pre-set somewhere. And see the values ... when you see a room with broken duration. |
|
@damencho |
|
I add log statements for debugging in function getMeetingCreatedTSConfig(room)
module:log('info', 'getMeetingCreatedTSConfig() returns %s for room %s', room.created_timestamp or "", room);
return {and function occupant_joined(event)
[...]
if participant_count > 1 then
if room.created_timestamp == nil then
room.created_timestamp = os.time() * 1000; -- Lua provides UTC time in seconds, so convert to milliseconds
else
module:log('info', 'Hook occupant_joined() says timestamp is already set: %s', room.created_timestamp);
end
endAnd this is Unix timestamp |
|
And the UI was showing something else? |
To be honest, I don't understand the question. The UI does not show the time but the duration of the current session. According to a logic that I don't understand yet, sometimes the counter at the beginning of a session is at 00:00 and gets stuck at this value, but sometimes the counter starts with the value of the length of a previous session and continues to count up. Could you please explain to me how the counter works in principle? From |
I was asking with the provided logs, what was the experience in the UI?
When the first occupant that is not jicofo (jicofo is the first to enter a meeting) joins and there is no created_timestamp for the room we store that value. When a client queries the room disco-info we put that value in the response, and from there the client can see when the meeting started and can start the counter from that time. The room object is destroyed once the last participant leaves the room and so is the value that was stored. |
|
Does this mean that the responsibility for increasing the counter is with the client? |
yes.
Yep, the disco-info response is handled here: https://github.com/jitsi/lib-jitsi-meet/blob/ec98b02095f806ca284d656965e2aba05bc0b2f8/modules/xmpp/ChatRoom.js#L377 |
In that particular example the UI displayed a 00:00 counter without counting up. But i did not expect any changes anyway since my code does not change anything. |
|
In the 0:0 case, I wonder was the disco info received. |
|
When this happens again, you can execute in the js console of the browser: |
I guess so since i don't see the |
|
@damencho Sry for the late reply, too much other work to do. I had to play around a bit because we start Jitsi via the iFrame API. Of course Starting the session the logs from (I used the same JWT twice to join the session with two participants) The counter was 00:00 and stayed that way. Using I assume that |
|
Good catch. Strange is that I cannot reproduce this. I set the same value in my local instance and tested it and I get: Seems it is some local lua locale setting or something ... strange. |
|
If you replace this line: with: room.created_timestamp = string.format('%i', os.time() * 1000); do you still reproduce receiving values like 1.71944e+12?
|
|
Yesss! This fixes the problem. I see a valid integer expression in @damencho , thank you so much for your help! |
What happened?
starting new conference, the timer is not starting at 0. not sure about it but it seems that it keep the IP / session from previous conference, whatever the room.
Exemple 1
I can open 3 conferences at different time and keep them running
/conferencetest1 started 30 min ago
/conferencetest2 started 10min ago
/conferencetest3 started 3min ago.
all 3 conferences are running with same timer value !
same if I open a conference /conference1 during 20min, then close it, and open a new one /conference2, the conference 2 will start at 20min because of previous one.
--> timer is unique
Platform
Browser / app / sdk version
chrome Version 125.0.6422.142 (Build officiel) (64 bits)
Relevant log output
No response
Reproducibility
More details?
No response
The text was updated successfully, but these errors were encountered: