Internet connection stability problems in version 26


New Member
I recently updated from OBS version 25, expecting a stable internet connection in live broadcasts, however, it was not like that. The connection is constantly lost creating spaces in which the same program passes it in reconnection.
Check the internet connection and it is stable im other programs

My pc is:
Processor: Core i5 8th
Ram: 16gb ddr4
Graphics Card: Intel 620 FHD
Ssd: 240gb
Model: HP 440 g5

Tanks You!.


Active Member


Active Member
I don't really know how to read crash logs, but my guess from the 26.0.0 logs is something to do with audio resampling as swresample-3.dll is an audio resampling library. Check your audio sources. Try to get them all on the same sample rate, preferably 48 kHz.
Also update to OBS 26.0.2 and does this happen on a stable build of Windows?


New Member
Hello, thank you very much for answering.

The windows version is stable, just update to the latest version. Although the audio sampling is configured at 48kHz, so I do not think that the audio is the problem since if so, nothing would be heard or sometimes the audio would not be heard.
My observations have been that every time the error happens, the hidden OBS icon appears in the notification bar as if something was loading! While the baud rate indicator is red !. After a while it stabilizes again, but the problem persists every 25 or 30 minutes!

I have tried Vmix program, and this one doesn't have that reconnection problem! I honestly do not know why.
Greetings and thanks!.


I'm making an educated guess here that the problem is in the NDI IP cam plugin or NDI HX driver.

The crash logs are showing at the time of the exception that when you close OBS, it doesn't shut down cleanly. A source in your scene is not closing down properly as its being destroyed on exit. There is still a lock on it and all the threads are sitting there waiting for the lock to be released.

Whats likely happening is that you are using a source multiple times across different scenes or from within one scene. That source is refusing to close down properly as there is a tricky condition due to a problem in coding that is preventing the lock to be released.

In your log, I see many threads using the NDI plugin for an IP camera. It could be that is the problem - the NDI IP Camera plugin that uses the Newtek HX Driver: Those threads are all sitting there in a zombie wait state waiting for the sources' lock to be released.

00007FFBA9010000-00007FFBA925D000 D:\Archivos de Programa\NDI-tools\NDI 4 Tools\HX Driver\x64\Processing.NDI.Plugins.IPCam.x64.dll

Go to NewTek and get help from them on this. If you want to try to solve this yourself, go download the current HX driver and install it. Then test again.


New Member
My question is if that intervenes in the stability of the connection,
since the program reconnects very often. That is, the connection is going great and suddenly, the signal drops and it remains reconnecting, it returns and continues normal and it drops again. It is not the network because the internet is stable!
Similarly, I will verify the NDI sources if it corrects the problem. Thanks for the answers and the help


According to the OBS log, most of the threads you have running show ndi.plugins.ipcam.x64 in the thread's call stack. An example is below:

00000084922FCF18 00007FFDF8D8BE14 0000000000000002 0000019903EC0230 000001997EB3EC40 00007FFD00000000 ntdll.dll!0x7ffdf8d8be14
00000084922FCF20 00007FFDF5C380FC 0000000000000A9C 0000000000000103 0000019903E3CBE0 0000000000000A84 mswsock.dll!0x7ffdf5c380fc
00000084922FCFC0 00007FFDF5C4DE0B 0000000000000A84 00000199040B49B0 00007FFD7985EE98 00000084922FD124 mswsock.dll!0x7ffdf5c4de0b
00000084922FD0C0 00007FFDF7263E74 0000000000000002 0000000000000000 0000970F860120D4 002277BF00000000 ws2_32.dll!0x7ffdf7263e74
00000084922FD170 00007FFD796B6199 0000000000000010 0000971B2A6D5038 0000970F860120D4 0000000000000013 processing.ndi.plugins.ipcam.x64.dll!0x7ffd796b6199
00000084922FF6C0 00007FFD796B53A9 0000000000000000 0000019903EAA8B0 0000000000000000 0000000000000000 processing.ndi.plugins.ipcam.x64.dll!0x7ffd796b53a9
00000084922FF700 00007FFD7967AED9 0000019903FA9DD0 0000000000000000 0000000000000000 0000000000000000 processing.ndi.plugins.ipcam.x64.dll!0x7ffd7967aed9
00000084922FF730 00007FFD79710DC0 0000000000000000 0000000000000000 0000000000000000 0000000000000000 processing.ndi.plugins.ipcam.x64.dll!0x7ffd79710dc0

The calling stack of this thread shows OBS invokes the NDI plugin.dll. Then, the Microsoft mswsocket.dll (WinSock programming API) gets called towards the top. There are many threads doing this and the IP network camera plugin never closes down.

Your logs show you got a lot of camera plugins running. I see in one log with 16 camera plugin instances. Do you even have the proper networking bandwidth support to be stable to support all these cameras?

Lets assume you have a 100Mbps (not Gigabit 1000) local network infrastructure and that an IP camera setup to send MJPEG sends 24Mbps data over the local network. If you got multiple IP cameras as NDi sources (lets say 16, you are already overloading the network (16 x 24Mbps = 384Mbps > 100Mbps). Include also the traffic from your return stream from Twitch/YouTube and what you are sending up to the Twitch/YouTube ingest server and now you are overloading you local area network even more. So yes, if you got a lot of cameras all sending MJPEG data over your 100Mbps network, you have network bandwidht overload. Your networked applications will have instability. your network itself will have shitload of dropped packets.

This is just an example for you to ponder if you need to make networking infrastructure changes to Gigabit, change data format to H.264 rather than MJPEG, and/or reduce the number of IP cameras.

As mentioned earlier though, I would go update the HW Newtek driver and the OBS NDI Plugin. If all this doesnt work, to talk to NewTek.


New Member
I already verified the connection
and removed some instances of the NDI plugin, as for the number of cameras and it worked correctly for me.
The network infrastructure was based on FastEthernet, which could limit data traffic a bit and cause packet loss. I will take these recommendations to apply it.