DNLA/UPnP and NDI are both failing (avahi in common), how do I debug this?

English Network/Internet
1

I have two reasons to think that avahi is failing badly on my openSUSE Tumbleweed installation: I cannot stream media from my NAS via DLNA and I cannot stream a camera feed from my iPhone to OBS Studio via NDI. In both cases, the service is not detected at all by the relevant applications on my openSUSE PC. Both of these rely on network autodiscovery protocols (UPnP, Bonjour) that should be enabled by avahi. I have searched the web and tried many things but I’m still stuck.

DLNA/UPnP media service from NAS

My NAS is configured to serve media via DLNA/UPnP. I’m quite sure that this works, because VLC on my iPhone immediately lists the name of my NAS as an UPNP service and I can see and play all files. However, my PC is not able to detect the service.

I tried the VLC RPM package from the Tumbleweed repository, VLC from Flathub and Kodi from Flathub; none of them detects the service from the NAS. (In VLC, I show the library column at the left with ctrl-L, then click UPnP, then wait for the waiting animation to go away, after which nothing is listed.) I found various things I could look for on the internet and tried all of the following, but none of them made a difference:

  • I verified that avahi-daemon was running (it already was).
  • I turned off IPv6.
  • I verified that the mdns service was enabled in the firewall (it already was).
  • I added the upnp-client service, UDP ports 1900 and 49153 and TCP ports 2869 and 49153 to the firewall.
  • I tried turning off the firewall entirely. It doesn’t appear to be a firewall issue.
  • I added my user to the avahi group (and also the video group, just in case it made a difference for the NDI issue).

After trying out all these things, still none of the DLNA-capable apps is detecting the DNLA media service. What else can I try? What logs might I consult in order to find out what is going wrong?

NDI camera stream from iPhone

I want to use my iPhone as a webcam on the PC. On my iPhone, I installed an app that makes its cameras available as NDI streams on the local network. On my PC, I installed OBS Studio and the Distro AV plugin, which adds NDI support to OBS Studio, both from Flathub. I also followed these and these instructions (except for the NDI installation instructions in the latter because NDI is already included with the Distro AV flatpak).

On the iPhone, I connect to wifi and disable wireless data to ensure that I’m broadcasting to the local network. Then, I start the NDI streaming app. It is very simple and starts filming and broadcasting right away. On the PC, I start OBS Studio, then in “Sources” panel at the bottom, click on the plus button and select “NDI Source”. In the floating window that appears, I choose “add existing”, but no existing NDI sources are listed. This is where avahi appears to be failing me.

I am not 100% sure that both issues have the same cause, but since both rely on avahi, I have a strong suspicion that this is the culprit. This is however more certain for the DLNA issue than for the NDI issue, because in the latter case, I have no other way to verify that the iPhone is actually broadcasting.

What might be wrong and how might I find out more? Any help much appreciated!

2

Welcome to openSUSE Forums.

To start with, please show what Avahi reports from the openSUSE host using avahi-browse -a. Make sure that mdns is allowed through the openSUSE firewall. I’m not sure that DLNA/UPnP is advertised this way though, (it uses SSDP). NDI does rely on mDNS.

For the DLNA/UPnP, SSDP (port 1900) is used, and there should be traffic evident, so tcpdump should capture that…
sudo tcpdump -ni <interface> udp port 1900
(Use the applicable interface for your LAN connection.)

You should observe M-SEARCH packets (clients searching for devices) and NOTIFY packets (servers announcing themselves). If not, I’d be checking your AP/router for multicast-related settings.

Also, show your current firewall configuration…

firewall-cmd --get-active-zones
firewall-cmd --zone=<zone> --list-services
firewall-cmd --zone=<zone> --list-ports
1 Like
3

I missed this on my initial read. If disabling the firewall made no difference and tcpdump shows no SSDP (udp/1900) or mDNS (udp/5353) traffic at all, then the issue is very unlikely to be on the openSUSE side.

The discovery protocols mentioned all rely on link-local multicast, so if multicast is dropped before it reaches the host, applications will never see each other regardless of firewall or Avahi configuration. For that reason, I would check client isolation, IGMP snooiping, or multicast settings in the AP/router.

4

Thank you for the quick reply.

+ enp1s0 IPv4 LOCALHOST (Stream Camera)                                  _ndi._tcp            local
+ enp1s0 IPv4 <redacted>@<redacted>                                    _raop._tcp           local
+ enp1s0 IPv4 <redacted>                                                 _airplay._tcp        local
+ enp1s0 IPv4 <redacted>                                                     _ssh._tcp            local
+ enp1s0 IPv4 <redacted>                                                   _daap._tcp           local
+ enp1s0 IPv4 <redacted>                                                   _smb._tcp            local
+ enp1s0 IPv4 <redacted>                                                   _afpovertcp._tcp     local
+ enp1s0 IPv4 <redacted>                                                   _device-info._tcp    local
+ enp1s0 IPv4 70-35-60-63.1 <redacted>                                   _sleep-proxy._udp    local
+ enp1s0 IPv4 <redacted>                                                 _companion-link._tcp local
+ enp1s0 IPv4 000000100000A99B                                           _fosquitto._tcp      local

The top one is almost certainly the NDI broadcast from my phone.

$ sudo tcpdump -ni enp1s0 udp port 1900

listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

I hit ctrl-C after a few minutes. With the -v flag added, the output changed a bit. I think all of these might be from the DLNA service, since it’s UDP port 1900 and 10.0.0.2 is my NAS:

tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
03:22:10.043120 IP (tos 0x0, ttl 4, id 48838, offset 0, flags [DF], proto UDP (17), length 451)
    10.0.0.2.42165 > 239.255.255.250.1900: UDP, length 423
03:22:10.043121 IP (tos 0x0, ttl 4, id 48839, offset 0, flags [DF], proto UDP (17), length 460)
    10.0.0.2.42165 > 239.255.255.250.1900: UDP, length 432
03:22:10.043175 IP (tos 0x0, ttl 4, id 48840, offset 0, flags [DF], proto UDP (17), length 503)
    10.0.0.2.42165 > 239.255.255.250.1900: UDP, length 475
03:22:10.043204 IP (tos 0x0, ttl 4, id 48841, offset 0, flags [DF], proto UDP (17), length 517)
    10.0.0.2.53470 > 239.255.255.250.1900: UDP, length 489
03:22:10.043253 IP (tos 0x0, ttl 4, id 48842, offset 0, flags [DF], proto UDP (17), length 515)
    10.0.0.2.48836 > 239.255.255.250.1900: UDP, length 487
03:22:10.043302 IP (tos 0x0, ttl 4, id 48843, offset 0, flags [DF], proto UDP (17), length 531)
    10.0.0.2.45310 > 239.255.255.250.1900: UDP, length 503
03:22:10.143530 IP (tos 0x0, ttl 4, id 48889, offset 0, flags [DF], proto UDP (17), length 451)
    10.0.0.2.58322 > 239.255.255.250.1900: UDP, length 423
03:22:10.143586 IP (tos 0x0, ttl 4, id 48890, offset 0, flags [DF], proto UDP (17), length 460)
    10.0.0.2.58322 > 239.255.255.250.1900: UDP, length 432
03:22:10.143641 IP (tos 0x0, ttl 4, id 48891, offset 0, flags [DF], proto UDP (17), length 503)
    10.0.0.2.58322 > 239.255.255.250.1900: UDP, length 475
03:22:10.143680 IP (tos 0x0, ttl 4, id 48892, offset 0, flags [DF], proto UDP (17), length 517)
    10.0.0.2.55070 > 239.255.255.250.1900: UDP, length 489
03:22:10.143775 IP (tos 0x0, ttl 4, id 48893, offset 0, flags [DF], proto UDP (17), length 515)
    10.0.0.2.34193 > 239.255.255.250.1900: UDP, length 487
03:22:10.143824 IP (tos 0x0, ttl 4, id 48894, offset 0, flags [DF], proto UDP (17), length 531)
    10.0.0.2.36473 > 239.255.255.250.1900: UDP, length 503
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

I don’t see these labels, but the above traffic does look like it originates from the DLNA service on my NAS. As for settings on the router, that seems an unlikely problem cause, since VLC on my phone is able to see the service.

$ firewall-cmd --get-active-zones

docker
  interfaces: docker0
home (default)
  interfaces: enp1s0

$ firewall-cmd --zone=home --list-services

dhcpv6-client ipp-client mdns samba-client slp ssh upnp-client

$ firewall-cmd --zone=home --list-ports

2869/tcp 5959/tcp 5960/tcp 6960/tcp 7960/tcp 49153/tcp 1900/udp 5353/udp 5959/udp 6960/udp 7960/udp 49153/udp
5

With respect to NDI, Avahi is working as expected, but since it is a sandboxed (Flatpak) application it may need to be granted network access to see local services via multicast/mDNS perhaps. I’m out of my depth here, but a quick search online search yileded

Try invoking flatpak override --user com.obsproject.Studio --share=networkand report back. Others may be able to assist further here if necessary.

With respect to SSDP, this is as expected…
10.0.0.2 → 239.255.255.250:1900
That’s form a DLNA/UPnP server sending NOTIFY advertisements.

Most DLNA clients rely on active discovery, sending an M-SEARCH packet, and getting a unicast reply from the server. It may ignore the multicast NOTIFY advertisements on the LAN. You could check that from the openSUSE host with
sudo tcpdump -ni enp1s0 udp port 1900 and host 10.0.0.2
and starting the client application. Are M-SEARCH packets evident?

1 Like
6

Flatseal can be used to adjust permissions and access per application or globally.

1 Like
7

Yes, I suspect that is the issue here.

8

Tried this, no difference.

I typed “flatseal” into KRunner and got the Application Permissions section of System Settings suggested to me as the first result. I hit enter on this option, found OBS Studio, and noticed that there was a “Manage Flatpak Settings” button in the top right corner. I presume this is a feature inside KDE’s System Settings that is enabled by Flatseal behind the scenes. Pressing that button, I saw lots of checkbox options, some enabled and some disabled. Of note:

  • Basic Permissions
    • Internet connection was on
    • Pulseaudio sound server was on
    • Device access was on
  • Advanced Permissions
    • Subsystems Shared
      • Inter-process communication was on
    • System Bus Policy
      • org.freedesktop.Avahi was set to talk

I presume the latter was the result of @deano_ferrari’s flatpak override command. To my untrained eyes, it looks like everything is already as it should be; I didn’t spot any settings with names that sound like they should be on but were actually off.

I checked the Flatpak settings for VLC as well and they were roughly the same, except that there was no permission to talk with Avahi over the system bus. I added it there for parity.

Could separate settings be needed for Distro AV, or for the NDI installation included with it?

I tried this several times, with and without -v added and with both the RPM VLC and the Flatpak VLC. In most cases, I saw no network packets whatsoever, just like in the first attempt in my previous reply. However, on my first attempt with RPM VLC, even though there was no output from tcpdump, I suddenly noticed that my NAS was actually listed in the UPnP section! I cannot explain why this happens now and didn’t happen earlier, except that there is a considerable delay (30-60 seconds) before the share appears. Maybe I have just been too impatient previously? Why does it need to take so long to appear?

Trying again with Flatpak VLC, the DLNA service is listed there as well. In this case the Flatpak Avahi permission might have made the difference.

Eventually, on my fourth attempt, tcpdump did produce 30 packets, all like this:

    10.0.0.2.55901 > 239.255.255.250.1900: UDP, length 129
21:29:06.167353 IP (tos 0x0, ttl 4, id 58215, offset 0, flags [DF], proto UDP (17), length 157)

So no M-SEARCH packages that I could recognize, but maybe tcpdump is not actually displaying all packets?

After realizing that my DLNA service not appearing in VLC might be due to a delay, I decided to switch on the camera server on my phone again and make another attempt in OBS Studio. Add an NDI source, pick “add existing”, and just leave the popup window open while writing this post. However, even after 5 minutes, I’m still not seeing my iPhone NDI service in that window.

I guess we can consider the DLNA issue fixed but not the NDI issue. What else can I try to diagnose this?

9

Flatseal isn’t “required” to manage flatpak permissions, on the Plasma Desktop, as a flatpak KCM is provided in the system settings.

I don’t think there’s anything that flatseal can do, that kcm_flatpak can’t, but some people prefer the flatseal interface.

3 Likes
10

A 30-60 second delay seems normal/expected behaviour. A server will only advertise itself periodically.

Once the Flatpak app was granted network / Avahi access, it could see the server’s NOTIFY advertisements (so that makes sense).

I can only speculate here. As you mentioned that applying the --share=network override did not help, it could be that the NDI issue is due to a plugin/runtime problem inside the OBS Flatpak itself.

The next diagnostic step would be to open a shell inside the Flatpak…
flatpak run --command=sh com.obsproject.Studio
Check for something like obs-ndi.so…
ls /app/lib64/obs-plugins/ | grep ndi
ldd /app/lib64/obs-plugins/obs-ndi.so | grep ndi
Report back with your findings.

1 Like
11

It took a little bit of trial and error, but I eventually found /app/plugins/DistroAV/lib/obs-plugins/distroav.so.

Neither of these commands gave output:

$ ldd /app/plugins/DistroAV/lib/obs-plugins/distroav.so | grep ndi
$ ldd /app/plugins/DistroAV/lib/obs-plugins/distroav.so | grep avahi

Piping | wc told me there are 94 other objects linked in there. I then took off the pipe and just read what was in there. Indeed nothing with ndi or avahi in the name. I haven’t looked at this type of diagnostic before but I noticed that 92 of them have this format:

        libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007ffb9e877000)

Two of them are different:

        linux-vdso.so.1 (0x00007ffb9e9a1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ffb9e9a3000)

I also took a closer look at the D-Bus access section of the page about Flatpak permissions that you linked to earlier. I noticed it discussed a way to diagnose missing permissions and followed the link to Audit session or system bus traffic. I tried both variants (session/system bus). greping for “require” yielded nothing in either case, but there were some errors on stderr including one about not being able to open a network socket in the system bus version. I pasted the entire output below in case anyone is able to make more of it than I am.

Qt: Session management error: Could not open network socket
debug: Found portal inhibitor
debug: Attempted path: /app/bin/../share/obs/obs-studio/locale/en-US.ini
debug: Attempted path: /app/bin/../share/obs/obs-studio/locale.ini
debug: Attempted path: /app/bin/../share/obs/obs-studio/locale/nl-NL.ini
info: Using preferred locale 'nl-NL'
debug: Attempted path: /app/bin/../share/obs/obs-studio/themes
debug: Attempted path: /app/bin/../share/obs/obs-studio/themes/
info: Using EGL/X11
info: CPU Name: AMD Ryzen 7 8840U w/ Radeon 780M Graphics
info: CPU Speed: 2054.670MHz
info: Physical Cores: 8, Logical Cores: 16
info: Physical Memory: 94322MB Total, 66945MB Free
info: Kernel Version: Linux 6.18.2-1-default
info: Flatpak Branch: stable
info: Flatpak Arch: x86_64
info: Flatpak Commit: 57c369da69c71c12b64543910ee525966ea39f3f5fd3990ea2e206ff707ea733
info: Flatpak Runtime: runtime/org.kde.Platform/x86_64/6.8
info: App Extensions:
info:  - com.obsproject.Studio.Plugin.DistroAV
info:  - com.obsproject.Studio.Locale
info: Runtime Extensions:
info:  - org.freedesktop.Platform.GL.default
info:  - org.freedesktop.Platform.openh264
info:  - org.gtk.Gtk3theme.Adwaita-dark
info:  - org.kde.Platform.Locale
info:  - org.freedesktop.Platform.GL.default
info: Flatpak Framework Version: 1.16.2
info: Desktop Environment: KDE (KDE)
info: Session Type: x11
info: Window System: X11.0, Vendor: The X.Org Foundation, Version: 1.21.1
info: Current Date/Time: 2026-01-02, 22:42:19
info: Browser Hardware Acceleration: true
info: Qt Version: 6.8.3 (runtime), 6.8.3 (compiled)
info: Portable mode: false
info: OBS 32.0.4 (linux)
info: ---------------------------------
info: ---------------------------------
info: audio settings reset:
	samples per sec: 48000
	speakers:        2
	max buffering:   960 milliseconds
	buffering type:  dynamically increasing
info: ---------------------------------
info: Initializing OpenGL...
info: Loading up OpenGL on adapter AMD AMD Radeon 780M Graphics (radeonsi, phoenix, LLVM 19.1.7, DRM 3.64, 6.18.2-1-default)
info: OpenGL loaded successfully, version 4.6 (Core Profile) Mesa 25.2.6 (git-3f12436d80), shading language 4.60
info: ---------------------------------
info: video settings reset:
	base resolution:   1920x1080
	output resolution: 1280x720
	downscale filter:  Bicubic
	fps:               30/1
	format:            NV12
	YUV mode:          Rec. 709/Partial
info: NV12 texture support enabled
info: P010 texture support not available
info: Audio monitoring device:
	name: Standaard
	id: default
info: ---------------------------------
warning: No AJA devices found, skipping loading AJA UI plugin
warning: Failed to initialize module 'aja-output-ui.so'
warning: No AJA devices found, skipping loading AJA plugin
warning: Failed to initialize module 'aja.so'
info: [pipewire] Available capture sources:
info: [pipewire]     - Monitor source
info: [pipewire]     - Window source
warning: v4l2loopback not installed, virtual camera not registered
info: [obs-browser]: Version 2.26.3
info: [obs-browser]: CEF Version 127.0.6533.120 (runtime), 127.0.0-6533-fix-stutter-and-osr-extra-info.3042+g176b09c+chromium-127.0.6533.120 (compiled)
info: VAAPI: API version 1.22
info: FFmpeg VAAPI H264 encoding supported
info: FFmpeg VAAPI AV1 encoding supported
info: FFmpeg VAAPI HEVC encoding supported
error: os_dlopen(libnvidia-encode.so.1->libnvidia-encode.so.1): libnvidia-encode.so.1: kan gedeeld objectbestand niet openen: Bestand of map bestaat niet

info: NVENC not supported
warning: Failed to initialize module 'obs-nvenc.so'
info: [obs-websocket] [obs_module_load] you can haz websockets (Version: 5.6.3 | RPC Version: 1)
info: [obs-websocket] [obs_module_load] Qt version (compile-time): 6.8.3 | Qt version (run-time): 6.8.3
info: [obs-websocket] [obs_module_load] Linked ASIO Version: 103200
info: [obs-websocket] [obs_module_load] Module loaded.
info: ---------------------------------
info:   Loaded Modules:
info:     distroav.so
info:     text-freetype2.so
info:     rtmp-services.so
info:     obs-x264.so
info:     obs-websocket.so
info:     obs-webrtc.so
info:     obs-vst.so
info:     obs-transitions.so
info:     obs-qsv11.so
info:     obs-outputs.so
info:     obs-libfdk.so
info:     obs-filters.so
info:     obs-ffmpeg.so
info:     obs-browser.so
info:     linux-v4l2.so
info:     linux-pulseaudio.so
info:     linux-pipewire.so
info:     linux-jack.so
info:     linux-capture.so
info:     image-source.so
info:     frontend-tools.so
info: ---------------------------------
info: ---------------------------------
info: Available Encoders:
info:   Video Encoders:
info: 	- ffmpeg_svt_av1 (SVT-AV1)
info: 	- ffmpeg_aom_av1 (AOM AV1)
info: 	- ffmpeg_vaapi_tex (FFmpeg VAAPI H.264)
info: 	- av1_ffmpeg_vaapi_tex (FFmpeg VAAPI AV1)
info: 	- hevc_ffmpeg_vaapi_tex (FFmpeg VAAPI HEVC)
info: 	- obs_x264 (x264)
info:   Audio Encoders:
info: 	- ffmpeg_aac (FFmpeg AAC)
info: 	- ffmpeg_opus (FFmpeg Opus)
info: 	- ffmpeg_pcm_s16le (FFmpeg PCM (16-bit))
info: 	- ffmpeg_pcm_s24le (FFmpeg PCM (24-bit))
info: 	- ffmpeg_pcm_f32le (FFmpeg PCM (32-bit float))
info: 	- ffmpeg_alac (FFmpeg ALAC (24-bit))
info: 	- ffmpeg_flac (FFmpeg FLAC (16-bit))
info: 	- libfdk_aac (libfdk AAC)
info: ==== Startup complete ===============================================
info: All scene data cleared
info: ------------------------------------------------
info: Device for 'Audio Output Capture' source Desktop-audio is also used for audio monitoring.
Deduplication logic is being applied to all monitored sources.
info: pulse-input: Server name: 'PulseAudio (on PipeWire 1.5.84) 15.0.0'
info: pulse-input: Audio format: s32le, 48000 Hz, 2 channels
info: pulse-input: Started recording from 'alsa_output.pci-0000_e5_00.6.analog-stereo.monitor' (default)
info: [Loaded global audio device]: 'Desktop-audio'
info: pulse-input: Server name: 'PulseAudio (on PipeWire 1.5.84) 15.0.0'
info: pulse-input: Audio format: s16le, 48000 Hz, 1 channels
info: pulse-input: Started recording from 'alsa_input.usb-046d_0825_96A5A210-02.mono-fallback' (default)
info: [Loaded global audio device]: 'Mic/Aux'
info: Switched to scene 'Scène'
info: ------------------------------------------------
info: Loaded scenes:
info: - scene 'Scène':
info: ------------------------------------------------
info: adding 21 milliseconds of audio buffering, total audio buffering is now 21 milliseconds (source: Desktop-audio)

info: Device for 'Audio Output Capture' source Desktop-audio is also used for audio monitoring.
Deduplication logic is being applied to all monitored sources.
info: ==== Shutting down ==================================================
info: pulse-input: Stopped recording from 'alsa_output.pci-0000_e5_00.6.analog-stereo.monitor'
info: pulse-input: Got 1214 packets with 1456800 frames
info: Deduplication logic stopped.
info: pulse-input: Stopped recording from 'alsa_input.usb-046d_0825_96A5A210-02.mono-fallback'
info: pulse-input: Got 1146 packets with 1375200 frames
info: All scene data cleared
info: ------------------------------------------------
12

Ok, what you’ve shared shows that NDI support is not actually present in the Flatpak plugin/runtime. The Flatpak OBS package includes the Distro AV plugin, but in this build it appears to be compiled without NDI support.

You could raise an issue for it…

2 Likes
13

Thanks for clarifying that. You linked to the issue tracker of OBS Studio proper, but isn’t this an issue with the plugin? Or does OBS Studio itself also have to be compiled with NDI support in order for the plugin to work?

14

Update: I submitted DistroAV#1390.

15

And another update: DistroAV works, too, and I was just misunderstanding how to use it. I had to pick “create new” first.

I basically made a lot of fuss about things that were working from the start. At least I learned a couple of things along the way. Thanks everyone for thinking along, especially @deano_ferrari.

1 Like
16

Thanks for the update. Always a challenge to diagnose things at a distance, hence we generally prefer commands and output over descriptions of what users think is happening.

2 Likes
17

As someone who maintains software that others use, I totally understand that preference. In this case, I did not know what commands to run and what output to share, so I described my issue as well as I could so that you could lead me to the right commands. If there had been an actual bug, I think our odds of finding the cause would have been quite good.

1 Like
18

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.