weird error messages

3 views
Skip to first unread message

Dave Stenhouse

unread,
Oct 18, 2025, 10:45:41 AM (2 days ago) Oct 18
to Mistserver.org
I have a scenario where I send an RTMP stream to a Mistserver, which records the stream locally and then forwards it to a second Mistserver again via RTMP. The second server is cloud hosted and is what clients connect to.
The first server has no errors, warnings, etc. but the second one has a flood of several messages that repeat. for example:
[17 Oct 2025, 17:42:16] MistOutHTTP (71847) [WARN] File descriptor 1 (returning 1) became invalid; removing from list (../build/lib/ev.cpp:157)
[17 Oct 2025, 17:43:41] MistController (815) [UPDR] You're running the latest version (../build/src/controller/controller_updater.cpp:92)
[17 Oct 2025, 17:46:01] MistOutHTTP (71879) [WARN] File descriptor 1 (returning 1) became invalid; removing from list (../build/lib/ev.cpp:157)
[17 Oct 2025, 17:49:51] MistOutHTTP (71993) [WARN] File descriptor 1 (returning 1) became invalid; removing from list (../build/lib/ev.cpp:157)
[17 Oct 2025, 17:53:14] MistOutHTTP (72017) [WARN] File descriptor 1 (returning 1) became invalid; removing from list (../build/lib/ev.cpp:157)
...
[17 Oct 2025, 19:00:47] MistController (815) [FAIL] Could not send UDP data through 16: Operation not permitted (../build/lib/socket.cpp:2778)
[17 Oct 2025, 19:00:52] MistOutRTMP:pboro_sda (72522) [FAIL] Could not send UDP data through 1: Operation not permitted (../build/lib/socket.cpp:2778)
[17 Oct 2025, 19:00:56] MistOutRTMP:pboro_sda (72516) [FAIL] Could not send UDP data through 14: Operation not permitted (../build/lib/socket.cpp:2778)
[17 Oct 2025, 19:00:57] MistOutRTMP:pboro_sda (72522) [FAIL] Could not send UDP data through 1: Operation not permitted (../build/lib/socket.cpp:2778)
[17 Oct 2025, 19:00:57] MistOutRTMP:pboro_sda (72522) [FAIL] Could not send UDP data through 1: Operation not permitted (../build/lib/socket.cpp:2778)

Watching the stream on the second server is perfect, no issues are observed. I also use a push to forward the stream to YouTube (via RTMP) and watching the stream on youtube also seems to be fine.
I suspect there's some aspect of the original stream that Mist is objecting to, but I don't understand why I wouldn't have the same errors on the first server.
server1 is running Mist 3.7
server2 is running Mist 3.8

Any ideas?

Balder Vietor

unread,
4:59 AM (10 hours ago) 4:59 AM
to mists...@googlegroups.com
Hey there,

For the MistOutHTTP messages: We found that issue and fixed it in the development builds. It was mostly a false alarm of a pipe still being active even though the other side was closed if I remember correctly. Basically MistServer still trying to serve the stream while the HTTP connection is closed. 

The MistOutRTMP is related to the internal statistics API, seems like it opened the wrong socket.... Highly likely that the internal stats of MistServer are somewhat of a mess. Now that isn't a problem for watching/viewing/sending streams, so you will probably not experience any bad streams from it. 

I'm suspecting one of the following is the problem:
- "localhost" is missing from /etc/hosts <- Meaning MistServer cannot find the local address and it cannot communicate statistics to itself
- MistServer isn't running at root level <- This would mean it isn't allowed to open certain ports, which could block this. Though it should have detected this and used different sockets.
- MistServer is attempting to use ipv6 addresses while the environment is blocking this <- MistServer auto-detects whether IPV6 is available or not, some servers report it available while also blocking everything that is send/received on IPV6. This could cause this behaviour as well.

The first case is easiest, simply check whether localhost is listed in `/etc/hosts` and add it if not. You'll most likely want it on both the ::1 and the 127.0.0.1 line. It's completely fine if it's mentioned twice like this:
 127.0.0.1      localhost
 ::1            localhost


This could also potentially be the fix for the 3rd case, removing the IPV6 line ::1 would have MistServer only attempt IPV4 addresses when `localhost` is considered. Though depending on the server configurations it might not be that simple.

Best,

Balder Vietor | Supreme tester



--
You received this message because you are subscribed to the Google Groups "Mistserver.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mistserver+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mistserver/f3c47daf-c132-481a-bcf9-db75788c547dn%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages