Negative call time

[ChristophWurst]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Steps to reproduce

1. Open a 1:1
2. Start a call
3. The other person can't connect because of media permission issues

Expected behaviour

Call timer shows reasonable time or only starts when both joined the call.

Actual behaviour

Call timer is negative

Talk app

Talk app version: (see apps admin page: /index.php/settings/apps)

Custom Signaling server configured: yes/no and version (see additional admin settings: /index.php/index.php/settings/admin/talk#signaling_server)

Custom TURN server configured: yes/no (see additional admin settings: /index.php/settings/admin/talk#turn_server)

Custom STUN server configured: yes/no (see additional admin settings: /index.php/settings/admin/talk#stun_server)

Browser

Microphone available: yes/no

Camera available: yes/no

Operating system: Windows/Ubuntu/...

Browser name: Firefox/Chrome/...

Browser version: 85/96/...

Browser log

``` Insert your browser log here, this could for example include: a) The javascript console log b) The network log c) ... ```

Server configuration

Operating system: Ubuntu/RedHat/...

Web server: Apache/Nginx

Database: MySQL/Maria/SQLite/PostgreSQL

PHP version: 8.0/8.1/8.2

Nextcloud Version: (see admin page)

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your server installation folder

Nextcloud configuration:

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your Nextcloud installation folder

Server log (data/nextcloud.log)

Insert your server log here

[Antreesy]

https://github.com/nextcloud/spreed/blob/master/src/utils/formattedTime.js#L9

if (!time || time < 0)

But we should investigate it deeper, to identify the source

UPD.: could the conversation.callStartTime timestamp be higher, than a current time?
https://github.com/nextcloud/spreed/blob/master/src/components/TopBar/TopBar.vue#L60

[DorraJaouad]

Was your browser time zone CET?
Was the absolute time increasing ( moving from -1 : -1 : -23 to -1 : -1 : -24 ...) or decreasing ( moving from -1 : -1 : -23 to -1 : -1 : -22 ...) ?

Maybe the callStartTime got overwritten by the message timestamp

spreed/src/store/messagesStore.js

Line 1070 in da83acc

properties: { callStartTime: message.timestamp },

The timestamp is in UTC time.

[nickvergessen]

Was your browser time zone CET?

yes should be

Was the absolute time increasing ( moving from -1 : -1 : -23 to -1 : -1 : -24 ...) or decreasing ( moving from -1 : -1 : -23 to -1 : -1 : -22 ...) ?

cc @ChristophWurst you remember that?

[ChristophWurst]

I do not remember unfortunately

[nickvergessen]

Closing for now, feel free to reopen or comment when it happens again

[devkonarev]

Same issue here.

Talk app version: 19.0.4
Nextcloud version: 29.0.3

1. Open a 1:1
2. Make a call, in my case from web UI to iOS client
3. Call established

web UI shows negative time, starting from -1:-3:-30 counting up -1:-3:-29, -28 etc
iOS client shows large positive time, 18446744073709551615:18446744073709551615 counting up.
After the time in the web UI reaches -1:-1:0 it resets on both clients to 00:00 and continues counting correctly.

Both clients and the server are in London/Europe timezone.

[nickvergessen]

you had the chance to look into the database what the active_since field is in the oc_talk_rooms table?

[lufer22]

Hey!!

I reproduced the same issue here.

The problem happens because there is a difference between the local machine clock and the server clock. When we start/join a call, the active_since field gets the server clock, and to show the correct timer, Talk calculates the difference between this field and the local machine clock, resulting in the problem.

Hope it helps! :D

[nickvergessen]

But the time is a timestamp and that is globally aligned to just +1 each second since 1st January 1970.
So shouldn't really matter in case of timezones and other things.

[Antreesy]

what the active_since field is in the oc_talk_rooms table

Can reproduce with manually changing the value of it in DB. But I assume, that only confirms server time might be incorrect?

[nickvergessen]

We experimented a bit yesterday, either server time is in the future or client time is in the past.
the samples here are at least 23 seconds for CW and 3m30s for devkonarev.
this is nothing we can easily fix. Best idea would be to just "store the offset" when the value is negative at some point and always add those offset seconds manually.

But if the client/server times are off, there can also be more/other issues (signaling messages from future, JWT token could be expired, ...) so we'll ignore it a bit longer until we have a better idea of what to do

[SystemKeeper]

To put it somewhere.

On talk-ios the issue is the same, but since we are converting to a string and assuming we have an unsigned int, we get the result as mentioned above.

One way to work around would be to make sure we don't have a negative duration on the client side: nextcloud/talk-ios#1757. This will result in the duration being "00:00" until we catched up with the server time.

If we want to have a correct duration, on way would be:

• Server sends callStartTime as timestamp (as it is now) and the current timestamp
• Clients are then able to calculate the offset between the client time and server time and adjust the duration accordingly.

Example:
Server sends callStartTime 1000 and currentTimestamp 1100
Clients current timestamp is 500, so we know we have an offset of 600 to the server time. So 500 + 600 - 1000 => 100 duration.

In the end, times should be correct one way or another and 3m30s offset is way too big and will lead to other issues (as mentioned above).
To prevent smaller time drifts I think just ignoring negative values is fine, everything else seems an issue on server/client side and not talk.