Jitter evaluation, as an alert trigger, was changed in 3.0 to get the internal
average jitter used in the conn-status component data (which is total jitter
delay divided by jitterbuffer emit events). This was done accidentally and that
metric is _very_ different from the one used in 2.7 (point-in-time jitter from
remote-inbound-rtp/inbound-rtp, highest on the interval, gathered on
/utils/stats.js). The alert thresholds were preserved, which makes it overly
sensitive in regards to jitter (and thus causes it to be critical whenever the
user is in audio).
Remove jitter as a connection status alert trigger, which fixes the
false positive. The implementation on <= 2.7 is also not ideal - if
anything, it generates false negatives. That's why I'm removing jitter for
the time being since it's ill-suited (at least in the way it's used)
for what we want to achieve.
* feat(graphql-server): add new view `v_chat_private_read_feedback`
Adds a view called `v_chat_private_read_feedback` to retrieve the last seen time
of the recipient of a private chat.
* refactor(chat): removes unused prop `lastSeenAt`
* feat(private-chat): message read confirmation feedback
Adds message read confirmation feedback feature to private chats.
This feature uses the private chat recipient's `lastSeenAt' attribute to
check which messages were read. Messages read are show in the chat with
a check icon next to it.
Feature behind a flag in settings.yml, which is disabled by default:
- `public.chat.privateMessageReadFeedback.enabled`
* fix(chat): poll chart message
Fixes poll chart message which was not using the full chat width due to
previous changes in chat messages `flex-direction`.
* fix: adds missing initial value for `privateMessageReadFeedback`
* fix: linter errors
* fix(chat): add `recipientHasSeen` property to existing view
This commit changes the way the messages read by the recipient are
tracked. The previous strategy required the client to calculate the read
messages and as a consequence all messages of the given chat
were re-rendered every time the recipient `lastSeenAt` time
changed. The current strategy consists of calculating the read messages
on the server(based on recipient `lastSeenAt`) and just expose to the
client a boolean(`recipientHasSeen`) for each message that indicates whether
it has already been read or not.
* fix: typo in message description
* fix: typo in settings flag
* fix: vertically align icon
* feat(webcams): skip video preview if valid input devices stored
Additionally:
- refactor: re-use the existing VirtualBackground_* storage info instead
of creating a new one
- fix: store background choices per deviceId instead of globally
- fix: guarantee background restore attempts are *critical* when
video-preview is supposed to be skipped. We want the preview to be
shown if the previous background could not be restored to preserver
the user's privacy choice
- fix: cameras could not be shared if no previous device info was in
the user's session
- fix: uploaded background images were not correctly restored
- fix: do not spin up virtual bg workers for brightness if it has not
been altered by the user
- refactor: remove old video-provider background restore routine,
centralize it in video-preview
* fix(skip-video-preview): correct storage check and add playwright test and docs
---------
Co-authored-by: prlanzarin <4529051+prlanzarin@users.noreply.github.com>
