reconnecting to the meeting randomly
-
wrote on Dec 31, 2024, 8:45 PM last edited by
grab some logs before you tag the dev?
-
wrote on Dec 31, 2024, 8:48 PM last edited by
@robi said in reconnecting to the meeting randomly:
grab some logs before you tag the dev?
it has not happen let so. i don't see the problem tagging the owner of the software he might know why
-
myself and others in the community sometimes get reconnected to the room
I am wondering if anyone else is experiencing this as well
maybe its a bug
wrote on Jan 1, 2025, 9:35 AM last edited by@mdc773 said in reconnecting to the meeting randomly:
myself and others in the community sometimes get reconnected to the room
The cause could be:
- Network Instability: Temporary internet disruptions, such as mobile devices switching between 3G and 4G, or high latency, may lead to participants reconnecting.
- Server Restarts: If the server is restarted, for instance, after updates, participants may reconnect when the MiroTalk instance becomes available again.
- WebRTC Behavior: WebRTC may renegotiate connections under certain conditions, which can appear as reconnections.
-
wrote on Jan 1, 2025, 9:40 AM last edited by
@robi said in reconnecting to the meeting randomly:
grab some logs before you tag the dev?
I agree. If anyone believe something is not working as expected, please follow this template to report it to us.
Thank you for your collaboration.
-
wrote on Feb 26, 2025, 8:36 PM last edited by mdc773 Feb 26, 2025, 8:37 PM
well we are still having the issues where at random time participant get kicked out the room or disconnects
Feb 26 14:31:48 peer_id: 'FTkmsYWM2d4mZt5FAAAD', Feb 26 14:31:48 peer_name: 'm@vigilante.media' Feb 26 14:31:48 } Feb 26 14:31:48 [2/26/2025, 20:31:48:187] [Server] [Disconnect] - peer name { peer_name: 'm@vigilante.media', reason: 'transport close' } +8s Feb 26 14:31:48 [2/26/2025, 20:31:48:188] [Peer] Producer "transportclose" event { producerId: 'ef3d56f3-c90e-4373-8e03-8271c1bcc6dd' } +1m Feb 26 14:31:48 [2/26/2025, 20:31:48:189] [Peer] Producer closed and deleted { Feb 26 14:31:48 peer_name: 'm@vigilante.media', Feb 26 14:31:48 kind: 'audio', Feb 26 14:31:48 type: 'simple', Feb 26 14:31:48 appData: { mediaType: 'audioType' }, Feb 26 14:31:48 producer_id: 'ef3d56f3-c90e-4373-8e03-8271c1bcc6dd', Feb 26 14:31:48 producer_closed: true Feb 26 14:31:48 } +0ms Feb 26 14:31:48 [2/26/2025, 20:31:48:190] [Peer] Producer "transportclose" event { producerId: '4343d7ac-1186-4d54-a29a-0fa45546242c' } +1ms Feb 26 14:31:48 [2/26/2025, 20:31:48:190] [Peer] Producer closed and deleted { Feb 26 14:31:48 peer_name: 'mellows@vigilante.media', Feb 26 14:31:48 kind: 'video', Feb 26 14:31:48 type: 'simulcast', Feb 26 14:31:48 appData: { mediaType: 'screenType' }, Feb 26 14:31:48 producer_id: '4343d7ac-1186-4d54-a29a-0fa45546242c', Feb 26 14:31:48 producer_closed: true Feb 26 14:31:48 } +0ms Feb 26 14:31:48 [2/26/2025, 20:31:48:191] [Room] ---> transport close [id:'5b14614c-5f7e-4cf4-a51b-aa2aa1886015'] +1m Feb 26 14:31:48 [2/26/2025, 20:31:48:191] [Peer] Closed and deleted peer transport { Feb 26 14:31:48 transportInternal: { Feb 26 14:31:48 routerId: '7ad8cd28-5822-4399-b159-a28dbfc56f51', Feb 26 14:31:48 transportId: '5b14614c-5f7e-4cf4-a51b-aa2aa1886015' Feb 26 14:31:48 }, Feb 26 14:31:48 transport_closed: true Feb 26 14:31:48 } +0ms Feb 26 14:31:48 [2/26/2025, 20:31:48:192] [Peer] Consumer "transportclose" event { consumerId: 'c6bbf162-07f6-438e-b8e8-f43e2e749f76' } +0ms Feb 26 14:31:48 [2/26/2025, 20:31:48:193] [Peer] Consumer closed and deleted { Feb 26 14:31:48 peer_name: 'm@vigilante.media', Feb 26 14:31:48 kind: 'audio', Feb 26 14:31:48 type: 'simple', Feb 26 14:31:48 consumer_id: 'c6bbf162-07f6-438e-b8e8-f43e2e749f76', Feb 26 14:31:48 consumer_closed: true Feb 26 14:31:48 } +0ms Feb 26 14:31:48 [2/26/2025, 20:31:48:193] [Peer] Consumer "transportclose" event { consumerId: '661b2825-3b1b-4af1-8b24-9296db3a63e6' } +0ms Feb 26 14:31:48 [2/26/2025, 20:31:48:194] [Peer] Consumer closed and deleted { Feb 26 14:31:48 peer_name: 'm@vigilante.media', Feb 26 14:31:48 kind: 'audio', Feb 26 14:31:48 type: 'simple', Feb 26 14:31:48 consumer_id: '661b2825-3b1b-4af1-8b24-9296db3a63e6', Feb 26 14:31:48 consumer_closed: true Feb 26 14:31:48 } +0ms Feb 26 14:31:48 [2/26/2025, 20:31:48:194] [Room] ---> transport close [id:'09a401c7-579a-406b-9261-ef36098553d6'] +3ms Feb 26 14:31:48 [2/26/2025, 20:31:48:195] [Peer] Closed and deleted peer transport { Feb 26 14:31:48 transportInternal: { Feb 26 14:31:48 routerId: '7ad8cd28-5822-4399-b159-a28dbfc56f51', Feb 26 14:31:48 transportId: '09a401c7-579a-406b-9261-ef36098553d6' Feb 26 14:31:48 }, Feb 26 14:31:48 transport_closed: true Feb 26 14:31:48 } +1ms Feb 26 14:31:48 [2/26/2025, 20:31:48:195] [Peer] CLOSE PEER - CHECK TRANSPORTS | PRODUCERS | CONSUMERS { Feb 26 14:31:48 peer_id: '3kGfBu-P62OrmafAAAAN', Feb 26 14:31:48 peer_name: 'm@vigilante.media', Feb 26 14:31:48 peerTransports: [], Feb 26 14:31:48 peerProducers: [], Feb 26 14:31:48 peerConsumers: [] Feb 26 14:31:48 } +0ms Feb 26 14:31:48 [2/26/2025, 20:31:48:196] [Server] [REMOVE ME DATA] { Feb 26 14:31:48 room_id: 'allwelcome', Feb 26 14:31:48 peer_id: '3kGfBu-P62OrmafAAAAN', Feb 26 14:31:48 peer_name: 'm@vigilante.media', Feb 26 14:31:48 peer_counts: 2, Feb 26 14:31:48 isPresenter: true
Hopefully this is log show the error?
-
wrote on Feb 26, 2025, 11:14 PM last edited by avatar1024 Feb 26, 2025, 11:16 PM
I'm also experiencing frequent disconnect with MiroTalk, especially when using Chromium, but also regularly with Firefox. It works fine with other conferencing software (Jitsi/Meet/Zoom/Teams). When I mean frequent I mean something like almost every 5min at times. And when not that frequent it is at least several times per meeting.
The message on screen is Producer transport closed, I get disconnected and it reloads and reconnects me right away. But still it is quite disturbing.
I can attach the full log if necessary but I think the relevant message may be something like this:
2025-02-24T12:28:52Z [[36m2/24/2025, 12:28:52:913[39m] [[33mServer[39m] [Disconnect] - peer name { peer_name: [32m'Gauthier'[39m, reason: [32m'transport close'[39m } [35m+2s[39m
@MiroTalk said in reconnecting to the meeting randomly:
The cause could be:
- Network Instability: Temporary internet disruptions, such as mobile devices switching between 3G and 4G, or high latency, may lead to participants reconnecting.
- Server Restarts: If the server is restarted, for instance, after updates, participants may reconnect when the MiroTalk instance becomes available again.
- WebRTC Behavior: WebRTC may renegotiate connections under certain conditions, which can appear as reconnections.
I can confirm that it is definitely not 2 as I'm not reboot the server and everything else on it runs just fine.
On 1., it indeed seems to happen more often when on mobile data. But again, it does not happen with any other platform. And it also happens (maybe a bit less frequently) when using the fibre broadband at home. On 3., possibly something to do with WebRTC, but in my case they are actual disconnections. I drop out of the meeting completely, MiroTalk shows the error message, then then and I get reconnected automatically.One thing I've noticed is that it seems less frequent (or even not happening) for people connecting from a Windows PC (I'm on Linux).
Nevertheless I have been promoting MiroTalk as it is a great piece of software otherwise. It's a real shame I have some reliability issues.
-
I'm also experiencing frequent disconnect with MiroTalk, especially when using Chromium, but also regularly with Firefox. It works fine with other conferencing software (Jitsi/Meet/Zoom/Teams). When I mean frequent I mean something like almost every 5min at times. And when not that frequent it is at least several times per meeting.
The message on screen is Producer transport closed, I get disconnected and it reloads and reconnects me right away. But still it is quite disturbing.
I can attach the full log if necessary but I think the relevant message may be something like this:
2025-02-24T12:28:52Z [[36m2/24/2025, 12:28:52:913[39m] [[33mServer[39m] [Disconnect] - peer name { peer_name: [32m'Gauthier'[39m, reason: [32m'transport close'[39m } [35m+2s[39m
@MiroTalk said in reconnecting to the meeting randomly:
The cause could be:
- Network Instability: Temporary internet disruptions, such as mobile devices switching between 3G and 4G, or high latency, may lead to participants reconnecting.
- Server Restarts: If the server is restarted, for instance, after updates, participants may reconnect when the MiroTalk instance becomes available again.
- WebRTC Behavior: WebRTC may renegotiate connections under certain conditions, which can appear as reconnections.
I can confirm that it is definitely not 2 as I'm not reboot the server and everything else on it runs just fine.
On 1., it indeed seems to happen more often when on mobile data. But again, it does not happen with any other platform. And it also happens (maybe a bit less frequently) when using the fibre broadband at home. On 3., possibly something to do with WebRTC, but in my case they are actual disconnections. I drop out of the meeting completely, MiroTalk shows the error message, then then and I get reconnected automatically.One thing I've noticed is that it seems less frequent (or even not happening) for people connecting from a Windows PC (I'm on Linux).
Nevertheless I have been promoting MiroTalk as it is a great piece of software otherwise. It's a real shame I have some reliability issues.
wrote on Feb 27, 2025, 12:59 AM last edited by@avatar1024 same here my team states that sometime every 2 to 5 mins it reconnects like almost every day
-
wrote on Feb 28, 2025, 2:19 AM last edited by
its be nice to find a solution
-
I’ve opened a thread here to discuss best strategies for handling unstable connections in mediasoup (built-in MiroTalk SFU server).
wrote on Mar 2, 2025, 7:32 AM last edited by avatar1024 Mar 2, 2025, 7:34 AM@MiroTalk said in reconnecting to the meeting randomly:
I’ve opened a thread here to discuss best strategies for handling unstable connections in mediasoup (built-in MiroTalk SFU server).
Really interesting thread, and making those changes for network interruptions might well work and do the trick for what we've experienced here (preventing the browser to close transport etc.).
I would just like to point out that in my case:
- There does not seem to be any network interruptions when the meeting connection drops. Everything else runs just fine, my wifi stays up and running, pages are loading, downloads are happening, etc.
- The connection to the meeting does already restart automatically, although I don't stay in the room. I am kicked out but I rejoin automatically (I don't need to manually refresh the page).
-
J jdaviescoates referenced this topic 21 days ago
-
wrote 6 days ago last edited by avatar1024 6 days ago
Things seems to have gone better for a while. But since the past couple of days it's gone really bad again. It feels like it is something on my end given other participants do not have those constant disconnections. Yet my internet seems very stable and for example with Jitsi or Teams (🤮) it's working totally fine and I have no disconnections...
I can't see anything in particular in the logs but happy to share the full log with @MiroTalk if useful.
I tried both with chromium and firefox and on two different servers (both cloudron with fresh install of mirotalk sfu)
-
Things seems to have gone better for a while. But since the past couple of days it's gone really bad again. It feels like it is something on my end given other participants do not have those constant disconnections. Yet my internet seems very stable and for example with Jitsi or Teams (🤮) it's working totally fine and I have no disconnections...
I can't see anything in particular in the logs but happy to share the full log with @MiroTalk if useful.
I tried both with chromium and firefox and on two different servers (both cloudron with fresh install of mirotalk sfu)
wrote 5 days ago last edited byI have created a bug report: https://github.com/miroslavpejic85/mirotalksfu/issues/200