Universal Media Server | Forum

Greetings! I am so relieved to get this problem FIXED that I want to post it for any other unfortunates who may be impacted...

Scenario: Happy UMS user for a few years... Serving from a Windows 10 system to a Samsung 46C670 TV. All is well and then....

Windows 10 announces that it needs to UPDATE my installation to version 1903 since 'support is ending' for my version. Okay... I let it happen overnight, like a good Windows user! A few days earlier (I recall) giving permission for JAVA to update in the Java 8 family (my fault... didn't pay too much attention) but then got a warning that I should PURGE older Java versions, which I declined, since I think they can usually run side by side... but I did wonder if any Java packages would be affected ...

I tell you all that to illustrate how convoluted a home Windows System upkeep can seem, and (spoiler alert) to show how easy it is for apparent complexities of the Windows 10 system to cast a dark shadow and confuse what are otherwise not so difficult problems.

As it happens, last night, I discovered that the TV could NOT find the UMS DLNA service. I hadn't used it since the Windows 10 Update. I immediately jumped to the foregone conclusion that either the Windows 10 update, or the Java Update or BOTH had corrupted ONE THING that worked well in this hoaky home network! Then I stayed up late into the early hours trying things to get the UMS server connection working again.

The UMS Service could see the TV, and could even control the TV Volume so I was baffled as to how this could break down so annoyingly ... (Curses, Oracle and Microsoft) ... I was sure it had to be the Windows Defender Firewall settings SOMEHOW.... That's what a lot of people here on the forum thought too.

So... Late into the night I tried:
- Reworking and resetting all the firewall settings.... Turning ALL the firewalls off with no help, then back on again in frustration.
- Resetting the router a few too many times.
- Installing/Uninstalling/Reinstalling UMS from the existing 8.0.1 package through 8.0.2, and finally to 9.0.0-b2, after searching through the forum to see if anyone else had this problem.

I got a few good hints, but no single concrete story that helped my case.

Finally I started watching the DEBUG LOG, and noticing the phrase... "Using address .... found on network interface: name:eth4 (Npcap Loopback Adapter)"... This was usually posted followed by information about the TV Renderer being REMOVED as NOT FOUND, even though it was still shown as available on the UMS Status page.

After reading more about 'Npcap Loopback Adapter', it became clear that this was probably not providing the expected pathway for the TV to find the Windows 10 computer, if it was doing anything at all. It also happened to be first on the list of network devices for UMS to try in the 'Network Settings (Advanced)' section. Forcing the WiFi Network to be the choice in the 'Force networking on Interface:' box DID NOT WORK either. It always resorted to using the 'Npcap Loopback' address over the real working WiFi interface, probably because the Npcap Loopback Adapter is a dummy virtual adapter that provides a usable response, since it is designed as a stand-in for network debugging, or something like that.

The SOLUTION I found was to DISABLE the Npcap Loopback Adapter in my Windows System Hardware Drivers list (not remove, just DISABLE for now.) When that was disabled, and UMS Restarted... the Log File now shows: 'Using address ... found on network interface: name:wlan2 (Qualcomm Atheros AR9485 Wireless Network Adapter)', and the expected behavior of the UMS and TV connection is restored!

Now, your problem may not be quite like mine, but BE SURE that you really study the DEBUG LOGS and see if you can get any hints as to why the Renderer's subscription is cancelled and dropped. This may have been caused the the Windows 10 update, say if the Npcap Loopback Adapter somehow got assigned a higher priority than the real WiFi adapter (I do not know how or why on that...), or maybe NOT. But the answer was staring me in the face within the LOGS all along. I only hope this gives you the kind of clue you need.

Forgive me for rambling ON and ON, but I am feeling really GREAT about UMS again, and appreciate all the work that is done to make this package succeed as well as it does!

Everything you write make sense except that it didn't work to manually select the WiFi interface in UMS' configuration. You shouldn't have to disable "Npcap Loopback Adapter", it should be sufficient to manually select the correct network interface and restart UMs.

That said, I don't know exactly what "Npcap Loopback Adapter" does. It seems to be a packet capturing "loopback adapter", that is a piece of software (a driver) that simulates a network device but in reality only inspects/logs the network packets passing through it. From what I understand, it is installed together with Nmap (https://nmap.org/) and WireShark.

Thanks a lot for sharing your success with us, and for your kind words about UMS! As Nadahar said, we do have a way to manually select network interface too, so you don't have to disable that in Windows itself

A Short P.S. to this Network Driver Selection story, after another day ...

Thanks to Nadahar and SubJunk comments, I took another look at forcing the WiFi Network to be the choice in the 'Force networking on Interface:' box... I really DOES work as intended. The problem was my rushed experiments and an incomplete investigation. I consistently MISSED observing that the drop down (showing available network choices) had a scrollbar, and I needed to scroll past the first 6 or 7 entries to find my REAL WiFi network driver closer to the bottom of the list. When I pick the real 'Qualcomm Atheros AR9485 Wireless Network Adapter' the issue is finally resolved within UMS. (Okay... I am too old to be red faced about every stupid thing I do on this PC ... I had only tried just picking one of the top 7 entries that looked more 'Microsoft'y than any of the others, betting that Windows 10 was just that convoluted. Not TRUE! ).

Another reason I had to take another look is that simply disabling the Npcap Loopback Adapter did not ultimately solve the problem, as there is something in the system that comes along and 'Enables' it again. Turns out that several month's ago I installed Wireshark just to experiment and learn a bit more about it, lost interest and then just let it sit there. Tonight I fully UNINSTALLED Wireshark and it took the Npcap driver away with it. It still bugs me a bit that a 'disabled driver' somehow gets 'enabled' without a related software program executing to account for it, but (hey...) that's a problem for another day. Besides that, it entices me to argue that Windows 10 really could be that convoluted. (Best excuse I've got for most things I don't understand )

As far as UMS is concerned, all is right with the world (again), except....

I "always" have WireShark installed (as I use it to debug network issues from time to time), and it has never caused me any trouble. I don't think the "Npcap Loopback Adapter" itself causes problems.

This is far from the first time (forced) Windows 10 updates rearranges the order of the network interfaces and thus leads to "unexpected change in behavior" as a consequence. It's actually quite common that this happens. Although I don't use Windows 10 myself (I'll stick with Windows 7 as long as possible, and probably migrate to Linux when it's too impractical to use), I think I have a pretty good idea what is happening: Microsoft hosts many 3. party drivers in a "Windowsified" edition. I'm not privy to the exact details of how this works, but I've seen the pattern consistently over many years. Many (3. party) drivers exists as updates on Windows Update. Microsoft obviously doesn't maintain these, but my guess is that they have some kind of requirement that for them to host the driver it shouldn't require a "specialized" GUI and conform to a bunch of "Windows rules" that makes them "look like" if they were a part of Windows. This isn't new with Windows 10.

What is new with Windows 10 is the forced updates. Previously, drivers wouldn't be updated unless you explicitly selected to do so. Now, I'm pretty sure that drivers that are hosted by Microsoft is forced upgraded together with all the other forced updates. This is what I think causes the order to be mixed up. Some of the "items" in the NIC list is effectively replaced (as if you first de-installed and then re-installed it). Since this list seems to be "FIFO", that means some drivers will "move to the back" during Windows updates, and voila: We have confusion

Made an account just to post this.
1) Thanks so much for pointing out the force networking on interface. I upgraded to Windows 10 and the computer could see the TV / phone, but nothing could see the computer. This fixed it right away after hours of reinstalling / troubleshooting firewalls.
2) If anyone has the same glitch I had: the Force networking on interface at first didn't have a scroll-down so I could only select loopback or some miniports. I selected ipv6 miniport (as a random guess). It didn't work, but after restarting the program the drop-down had a scroll bar to select my actual wireless adapter.

Thank you, it solved my problem here too !

I'll detail a bit more so that someone can find this thread with proper keywords.

The same problem appeared after I installed VMware, a software to emulate virtual machines. It added 2 network cards in my Windows 10 : VMware Virtual Ethernet Adapter for VMnet1 & VMnet8. Since then, UMS could still detect my TV, but my TV couldn't find UMS server anymore.

Problem could be solved by :
- Best option : selecting the proper network adapter in UMS > General parameters > Network parameters (advanced) > Force network interface ;
- Or disabling those 2 network cards in the Device Manager.