mirror of
https://github.com/suitenumerique/meet.git
synced 2026-09-02 13:48:26 +00:00
kaelvar
1ac1778521
`handleVideoResolutionChange` did all of its work inside `if (videoTrack)`, including `saveVideoPublishResolution`. With the camera off there is no camera publication, so choosing a resolution did nothing at all: it was neither applied nor recorded, while the selector went on showing the value the user had just picked. Turning the camera back on then published at the old resolution, and so did the next session. Found on a self-hosted instance: a user set the sending resolution with the camera off, turned it back on, and the publisher kept sending 720p. Nothing in the UI suggested the choice had been dropped. Persist the choice first and unconditionally, then restart the track only when there is one to restart. Persisting alone is not enough within a session. `roomOptions` is only read by `new Room(...)`, so a store update never reaches a room that is already built. Sync the VideoDeviceControl with the userChoiesStore resolution, as we did for the device id and the processor configuration. The early return is the honest shape here: with no live track there is nothing to await, and the defaults above already cover what happens next.