Servii0 2.1 on Raspberry Pi 3B will not stream to DLNA

After testing successfully using a Windows 10 Server, I decided to install Serviio on my Raspberry Pi 3, Model B (running Linux 10 - buster) since I don't want my Windows server on 24x7.

I followed the instructions available below installing Serviio v 2.1 rather than 1.9 since that is what I used under Windows. There were no issues, and the service is reported as "Active (running)" by the OS.
https://linuxconfig.org/how-to-install-serviio-media-server-on-raspberry-pi

I was able to run the Serviio console on a browser using another PC on the LAN, and setup my Shared Folders. This kept the Pi busy for about an hour gathering metadata. After that I tried accessing the DLNA server on my TVs. Three of my TVs have Rokus attached and I use the Roku Media Player for this. I also have an LG Smart TV with DLNA app. With both these setups, the Serviio Server does not show up as a Media Device. so I am unable to watch content. Again, this works on both the LG and Roku devices when Windows is used to serve Serviio.

Does anyone have any suggestions for getting this to work on the Pi?

[atc98092]

Just a guess, and I have no idea how to check it, but it sounds like there's a firewall issue with your Linux install. The console is browser based, and uses different ports then the uPnP protocol that DLNA uses. I run all my Windows PCs in the house without a firewall, because I'm comfortable with who's accessing my network.I believe UDP port 1900 is the one that is used for broadcasting the server's existence, so that's the first to check.

Thanks Dan,

The Raspberry PI has no running firewall by default, and I confirmed that all Inbound, Outbound and Passthrough traffic is allowed.

I did get Serviio to appear on my Roku and TV devices as a media server when I switched those devices from my home "Guest" network to our "Private" network. The Pi and Windows servers are on a Wired LAN, and we have a wireless access point that provides logical networks for guests and private use. With few exceptions, guests do not have access to LAN resources. DLNA services from multiple servers had been an exception. Serviio running on the Pi can not get through to the guest WLAN to "announce their service" but under Windows it can.

One possible reason would be Serviio using different ports under the two OSs. Another possibility is a difference in how the two create multicast packets to broadcast the service (in Windows perhaps the source address is not on the LAN whereas in Linux it is?). In either case, I'd need an app to capture packets generated on both systems and considerable time.

I don't have a problem with the TVs and Rokus being on the "Private" LAN with my Servers, Laptops, etc., but never had to previously. If there was no need to provide that access, I 'd choose not to for the added security.

If anyone could add any insight..

[atc98092]

OK, I didn't realize you were using a guest WAP. That would absolutely cause it.

If DLNA ever worked through on the guest connection in the past, I'm surprised. Normally guest access points allow only Internet access, and nothing on the local LAN is supposed to be available. uPnP uses the same port, regardless of OS, and Serviio also uses the same ports on all OS types. Could Windows do something different with Multicast? Certainly, and it wouldn't be the first time they've done things that weren't "standards based".

One "Final" thing I needed to do to stabilize the environment with the Raspberry pi should anyone read this link for help with a similar setup..

The Serviio Server disappeared from the Roku Media player device list after 30 minutes or so. Rebooting the Pi, or stopping/restarting the service, would bring it back for another thirty minutes. Looking through the forum I saw others using Unix based servers having similar problems about 8 years ago. Well their fix worked for me too, but I have no idea why.
On the pi, as admin, I edited the /etc/network/interfaces file, adding 1 line and some comments as follows. Rebooted the pi and the disappearing server was resolved.

# The following line added to support Serviio multicast stability
# eth0 is the pi's ethernet port, 239 is a multicast subnet (used by Serviio?)
# command forces all outbound traffic to 239.x.x.x through ethernet port
# No idea why this works though
up route add -net 239.0.0.0 netmask 255.0.0.0 dev eth0