feat(track-state): Log on add/remove/mute/owner. #13934
Conversation
| @@ -845,7 +845,7 @@ export default { | |||
| // This will only modify base/media.audio.muted which is then synced | |||
| // up with the track at the end of local tracks initialization. | |||
| muteLocalAudio(mute); | |||
| this.setAudioMuteStatus(mute); | |||
| this.updateAudioIconEnabled(); | |||
There was a problem hiding this comment.
Do we even need to call it here? What is the purpose of checking here if the audio icon needs to be enabled or disabled.
| @@ -1394,7 +1394,7 @@ export default { | |||
| APP.store.dispatch( | |||
| replaceLocalTrack(oldTrack, newTrack, room)) | |||
| .then(() => { | |||
| this.setAudioMuteStatus(this.isLocalAudioMuted()); | |||
| this.updateAudioIconEnabled(); | |||
| APP.conference.setAudioMuteStatus(muted); | ||
| } else { | ||
| APP.UI.setAudioMuted(participantID, muted); | ||
| APP.conference.updateAudioIconEnabled(); |
There was a problem hiding this comment.
Same question here again. If we already know that a local audio track exists, why do we need to check if the mic icon needs to be enabled or disabled?
| @@ -62,7 +71,32 @@ MiddlewareRegistry.register(store => next => action => { | |||
|
|
|||
| case TRACK_REMOVED: { | |||
| _removeNoDataFromSourceNotification(store, action.track); | |||
| break; | |||
|
|
|||
| const result = next(action); | |||
There was a problem hiding this comment.
Do we need to log it here since with ssrc-rewriting, tracks will never be removed.
There was a problem hiding this comment.
It could be useful for the case where the ssrc rewriting is not enabled.
There was a problem hiding this comment.
Even without ssrc rewriting, remote tracks are removed only when participants leave. Do you think track states will be helpful in that case. I am just worried about all the unnecessary logging.
|
About your questions related to the first commit: Will check on the specific places that you pointed out if we actually we need to call the function although IMHO this is totally different story. |
|
It seems that we try to update it whenever we do changes to the local tracks or devices. On some places it may be redundant but I think the whole thing needs to be refactored. In addition this is old logic which dispatches an action and changes the store which may have other implications. I'm worried to just remove some of the places in order not to break some weird use case. So lets leave it for another PR. |
No description provided.