Skip to content

Conversation

@kbalt
Copy link
Contributor

@kbalt kbalt commented Jan 9, 2025

Currently there's no way to know when a track was muted by a moderator since track changes from the server were ignored.

This updates the TrackInfo of the local participant in a similar way, to how its done for remote participants.

While this seems to work, I'm not sure if this is the correct way to do this, since the comment in https://github.com/livekit/rust-sdks/blob/main/livekit/src/room/publication/remote.rs#L157 seems to imply that this should already work for local publications?

@ilo-nanpa
Copy link
Contributor

ilo-nanpa bot commented Jan 9, 2025

it seems like you haven't added any nanpa changeset files to this PR.

if this pull request includes changes to code, make sure to add a changeset, by writing a file to .nanpa/<unique-name>.kdl:

minor type="added" "Introduce frobnication algorithm"

refer to the manpage for more information.

@kbalt kbalt changed the title feat: emit track-muted event for local tracks fix: emit track-muted event for local tracks Jan 9, 2025
@kbalt kbalt force-pushed the local-track-muted-event branch from 36905ef to 42bd9c5 Compare January 9, 2025 16:04
@kbalt kbalt force-pushed the local-track-muted-event branch from 42bd9c5 to d8bb6e2 Compare February 6, 2025 12:50
@davidzhao davidzhao requested a review from typester February 17, 2025 06:43
@kbalt kbalt force-pushed the local-track-muted-event branch from d8bb6e2 to abc6ed5 Compare May 6, 2025 10:41
@kbalt kbalt force-pushed the local-track-muted-event branch from 702f3ff to bf56220 Compare June 3, 2025 16:41
@kerkmann
Copy link

kerkmann commented Jun 30, 2025

@davidzhao @typester any progress with this pr? :)

@kbalt kbalt force-pushed the local-track-muted-event branch from bf56220 to c73496b Compare July 8, 2025 12:01
@sandr01d
Copy link

Running into the same issue. Any chance this can be moved forward?

@ladvoc
Copy link
Contributor

ladvoc commented Aug 29, 2025

Hi @sandr01d, I will look into this.

@kbalt kbalt force-pushed the local-track-muted-event branch from c73496b to 6dd9315 Compare August 29, 2025 12:41
@kbalt kbalt force-pushed the local-track-muted-event branch from 6dd9315 to 25ec35c Compare October 28, 2025 15:00
@kbalt kbalt force-pushed the local-track-muted-event branch from 25ec35c to 4f85f7a Compare November 28, 2025 16:34
@davidzhao davidzhao requested review from cloudwebrtc, ladvoc and xianshijing-lk and removed request for typester November 28, 2025 22:53
@xianshijing-lk
Copy link
Contributor

Thanks @davidzhao for looping me in. Looking at the code, I think it is doing the right thing, the existing Rust code assumes the the local participant does not need the event as the mute happen starting from the UIs, thus they don't need an event to notify them back.
With a moderator mute behavior, this assumption is not correct any more, instead, they will need an event to get notified so that they can update the UI correspondingly.

Think about it for two use cases, if users update the UI to mute / unmute, then will get the redundant events, but that will be fine, since apps should not nothing if they check the cached value is the same as the mute value in the event, then do nothing.
If moderator mute / unmute the local participant, apps will find a mismatch values, then they will update the UI to notify the users.

the PR looks good to me in general. That says, I am pretty new to the our Rust SDK, please let me know if I miss anything. @ladvoc, do you have any concern of landing it ?

BTW, thanks for the PR and sorry for the length review process.

@cloudwebrtc
Copy link
Contributor

The code looks good, but I need to confirm whether on_mute/on_unmute will be triggered twice.

https://github.com/livekit/rust-sdks/blob/main/livekit/src/room/track/mod.rs#L203-L209

Copy link
Contributor

@ladvoc ladvoc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, see one comment.

Copy link
Contributor

@ladvoc ladvoc Dec 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This repository no longer uses the nanpa release manager, so this file should be removed before merging.

@cloudwebrtc
Copy link
Contributor

I just created another fix and verified it.

#799

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants