MiroTalk Update regularly fails after update

[MiroTalk]

@james said in MiroTalk Update regularly fails after update:

Does this have any other effects?

In theory, it shouldn’t have any other effects, as long as the user can switch between these two modes. I’m not entirely sure why Mediasoup doesn’t use a server SFU by default, but you could ask the Mediasoup support forum for clarification.

[djxx]

Is there any update on this? I can't rely on this app for meeting links because about 75% of the time it's not running properly due to startup failure.

[nebulon]

So this always happens when the app gets updated?

[djxx]

@nebulon It also happens after system updates or restarts. It seems it's a roll of the dice if the ports aren't already taken. Restarting the app doesn't fix it anymore, so now when it crashes I change the SFU TCP/UDP port range to something else and it works when the app restarts.

[robi]

Sounds like a firewall cleanup issue or maybe something in between

[nebulon]

When this happens, can you check which container is occupying those ports?

You can run

docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Ports}}" | grep <portnumber>

which should reveal the container holding on to it.

[MiroTalk]

@djxx said:

Restarting the app doesn't fix it anymore, so now when it crashes I change the SFU TCP/UDP port range to something else and it works when the app restarts.

This issue can occur if another application is already using ports within the 40000–40100 range. To resolve it, you can either change the port range (for example, starting from 25000)

or enable WebRTC server mode in the env (edit it via Cloudron file manager), which requires fewer ports, as described above.

SFU_SERVER=true

Then restart the instance.

Edit: The second option requires implementation on the Cloudron side, as described here:
https://forum.cloudron.io/post/117374

[robi]

Why don't we have the second option as the more reliable packaged default?

[girish]

@djxx I think https://git.cloudron.io/platform/box/-/commit/b08e3a5128cdf2e036523c6d585adb0674ba95bf will help.

[djxx]

It's happening again, and this time I don't see a container conflict but rather a health check failure that it cant find it's public IP:

Mar 30 09:06:14 [3/30/2026, 16:06:14:098] [Server] Failed to detect IP from http://api.ipify.org 'getaddrinfo EAI_AGAIN api.ipify.org'
Mar 30 09:06:14 [3/30/2026, 16:06:14:101] [Server] Failed to detect IP from http://ipinfo.io/ip 'getaddrinfo EAI_AGAIN ipinfo.io'
Mar 30 09:06:14 [3/30/2026, 16:06:14:102] [Server] Failed to detect IP from http://ifconfig.me/ip 'getaddrinfo EAI_AGAIN ifconfig.me'
Mar 30 09:06:14 [3/30/2026, 16:06:14:103] [Server] Public IP detection failed 'All public IP detection services failed! Please check your network connection'
Mar 30 09:06:14 ⠙
Mar 30 09:06:23 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.16.130:3010

When I check what is using port 3010, it's nodeJS running /home/yellowtent/box/box.js

[MiroTalk]

Mar 30 09:06:14 [3/30/2026, 16:06:14:098] [Server] Failed to detect IP from http://api.ipify.org 'getaddrinfo EAI_AGAIN api.ipify.org'
Mar 30 09:06:14 [3/30/2026, 16:06:14:101] [Server] Failed to detect IP from http://ipinfo.io/ip 'getaddrinfo EAI_AGAIN ipinfo.io'
Mar 30 09:06:14 [3/30/2026, 16:06:14:102] [Server] Failed to detect IP from http://ifconfig.me/ip 'getaddrinfo EAI_AGAIN ifconfig.me'
Mar 30 09:06:14 [3/30/2026, 16:06:14:103] [Server] Public IP detection failed 'All public IP detection services failed! Please check your network connection'

This looks like a network-related issue rather than something specific to MiroTalk.

If SFU_ANNOUNCED_IP is not configured, the system will automatically rely on three external services to determine the instance’s public IPv4 address.

---

Is there a firewall or network filter in between that might be blocking traffic?

---

NOTE: As I can see, on Cloudron this is handled by the command in:
https://git.cloudron.io/packages/mirotalksfu-app/-/blob/main/start.sh#L39

If it fails (mean not set SFU_ANNOUNCED_IP), MiroTalk SFU uses an internal fallback mechanism that queries three external services in sequence to determine a valid public IPv4 address for the instance.

[djxx]

@MiroTalk I can't speak for what Cloudron is doing - but after changing the port ranges again and restarting the app, it starts working again. Perhaps there's a step (getting the public IP) that only happens on reconfiguration but the app expects it to happen on every start?

[girish]

@djxx unfortunately, my fix (in 9.1.6) did not work. I am looking into a more involved fix.

[girish]

I missed a retry in start container - https://git.cloudron.io/platform/box/-/commit/4ba9c63eb41d663e805f72257cc37774f401265b