I recently got to the bottom of a very longstanding problem where I’ve been unable to get a DLNA media server (minidlna) to reliably work when running on my home server. Although it would work for a minute or so after starting up, the server would then disappear from the client’s view, and I came to the conclusion a long time ago that minidlna was just unreliable. Running a different DLNA server, rygel, on another machine is fine, but I don’t want to leave both machines on all the time.
Having bought new hardware for the server a few days ago, I wanted to get it running again on the server so I could turn the desktop off when I’m watching video on the tablet. So I ran tcpdump on the server to watch what was happening… and it suddenly all worked perfectly. Stopping tcpdump caused it to break again. This led to the realisation that enabling promiscuous mode on the ethernet bridge with ‘ifconfig br0 promisc’ fixed the problem, though I didn’t know what the problem actually was. Turning the firewall off didn’t help, either.
Quite a lot of digging on the Internet later and I found that there seems to be a bug in the Linux bridging code for multicast, other than the common 184.108.40.206/24 range. DLNA uses SSDP (UPnP) with multicast IP address 220.127.116.11, and those packets weren’t getting through after a while. As I run virtual machines on the server, the main ‘internal’ network interface is a bridge.
The solution (though it is still a workaround as far as I can tell, though likely less intrusive than enabling promiscuous mode) seems to be to disable multicast snooping on the bridge interface, something like the following:
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping
I have not investigated why rygel always works fine on the desktop machine, as that also has a bridge as its main interface. But at least I can easily stream video to the tablet now with the desktop machine turned off!