Fix tracks not being resumed in case of a startPublishing vs track

[toger5]

Content

We make sure to resume upstream in case startPublish failed to do so (resumeUpstreams failed)
We can see this in the logs:
No track found for source

12:46:46.324 org.matrix.rust.sdk     io.element.android.x.debug           D  elementx: [ElementCall] :2 [CallViewModel][Publisher https://livekit-jwt.call.matrix.org] startPublishing called | ConsoleMessageLogger.kt:49
12:46:46.326 org.matrix.rust.sdk     io.element.android.x.debug           W  elementx: [ElementCall] :2 [CallViewModel][Publisher https://livekit-jwt.call.matrix.org] No track found for source microphone to resume upstream | ConsoleMessageLogger.kt:49
12:46:46.327 org.matrix.rust.sdk     io.element.android.x.debug           W  elementx: [ElementCall] :2 [CallViewModel][Publisher https://livekit-jwt.call.matrix.org] No track found for source camera to resume upstream | ConsoleMessageLogger.kt:49

(this was found with the help of an LLM)

Motivation and context

https://matrix.to/#/!yuFzMhMqKzNFvoLqcJ:one.ems.host/$6qF5LPK58oJPOqGDLOBs-Hsb52oAPksA-3ifz9jVQqI?via=matrix.org&via=element.io&via=lant.uk

Screenshots / GIFs

Tests

@jmartinesp needs to test with a device where this race occurred

Checklist

• A linked, pre-approved issue exists for this feature or UI change.
• I have read CONTRIBUTING.md in full.
• Pull request includes screenshots or videos for any UI changes.
• Tests written for new code (and existing touched code where feasible).
• Linter and other CI checks pass.
• I have licensed the changes to Element by completing the Contributor License Agreement (CLA)

[robintown]

This isn't making sense to me… if no tracks are found on which we can resumeUpstream, how would we have previously found any tracks on which to pauseUpstream? And what would've caused the app to pauseUpstream in the first place? (I don't see any mention of pausing in Jorge's logs.)

Less relatedly, the startPublishing and stopPublishing methods appear to be misnomers as they deal with pausing and resuming media streaming rather than track publications.

[jmartinesp]

I can still tests this, as it takes a minute to do it: I'd just need some deployed URL.

---

Tested this using the deploy url below and I still see the same behaviour, sorry.

[BillCarsonFr]

Less relatedly, the startPublishing and stopPublishing methods appear to be misnomers as they deal with pausing and resuming media streaming rather than track publications.

Yeah it is because we don't have control other track creation vs publication. The initial design wanted to do that (hence the current naming), so it was creating the track and publishing which ultimatly was creating duplicate tracks. The livekit "highlevel" mode auto publish tracks once created, so the closest thing we can do is to pause the stream.

The fix for that is to create our own low level track management API instead of the livekit one.

[toger5]

This isn't making sense to me… if no tracks are found on which we can resumeUpstream, how would we have previously found any tracks on which to pauseUpstream? And what would've caused the app to pauseUpstream in the first place? (I don't see any mention of pausing in Jorge's logs.)

Less relatedly, the startPublishing and stopPublishing methods appear to be misnomers as they deal with pausing and resuming media streaming rather than track publications.

I am also not yet 100% convinced.

how would we have previously found any tracks on which to pauseUpstream

    // Resume upstream for both audio and video tracks
    // We need to call it explicitly because call setTrackEnabled does not always
    // resume upstream. It will only if you switch the track from disabled to enabled,
    // but if the track is already enabled but upstream is paused, it won't resume it.
    // TODO what about screen share?

Is valeres comment on the startPublishing function. So we do have some inconsistency on setTrackEnabled -> upstream being started/not started.

So there is no mention of pausing because they already start in pasused state like valere has observed.
startPublishing basically just sets shouldPublish=true + tries resuming upstream.

Less relatedly, the startPublishing and stopPublishing methods appear to be misnomers

I am a bit confused by lk here. I think calling publish creates a publication but does not always imply that you actuality send them upstream. you can publish without upstreaming (I think).

[toger5]

@jmartinesp
Just to double check
https://pr4087--element-call.netlify.app/room is what you used in your EX dev config?

[jmartinesp]

@jmartinesp Just to double check https://pr4087--element-call.netlify.app/room is what you used in your EX dev config?

Yes, I could still reproduce the issue. I even tried using it on both ends (EW, EXA).

[toger5]

Yes, I could still reproduce the issue. I even tried using it on both ends (EW, EXA).

I added additional logs. Maybe you can do one more rageshake.

[jmartinesp]

Done (rageshake mentions this PR).

[toger5]

Done (rageshake mentions this PR).

Oh no it seems we are not getting EC logs again...

but it also says:

Version: embedded-v0.20.1

[jmartinesp]

That's the version in Element Web though (technically, Element Desktop)? There is another rageshake containing the info from the EXA device.

[toger5]

That's the version in Element Web though (technically, Element Desktop)? There is another rageshake containing the info from the EXA device.

Found it.