Add DLNA Receiver plugin provider

[trudenboy]

Summary

New plugin provider that exposes Music Assistant as a UPnP/DLNA MediaRenderer on the local network. External apps (BubbleUPnP, Qobuz, foobar2000, mconnect, etc.) can discover MA via SSDP and cast audio streams to any configured player.

Key features

• SSDP discovery — advertises virtual MediaRenderers via multicast (239.255.255.250:1900)
• Multi-player mode — one renderer per MA player (e.g. "Music Assistant — Kitchen"), each with a unique UDN and HTTP port
• DIDL-Lite metadata — parses title, artist, album, cover art, duration from control point metadata
• Elapsed time tracking — continuously updates progress in MA UI via StreamMetadata
• Audio proxy — streams audio URL through PluginSource / get_audio_stream() into the MA pipeline
• GENA eventing — UPnP event subscriptions for AVTransport, RenderingControl, ConnectionManager
• Recursion filter — own renderers are excluded from the player list to prevent feedback loops
• Full SCPD — complete service description XMLs for all three UPnP services

Architecture

DLNA Control Point
       │
       ▼
  SSDP Discovery ──► UPnP HTTP Server (SOAP actions)
                           │
                           ▼
                    PluginSource bridge
                           │
                           ▼
                    MA streaming pipeline ──► Target Player

Changed files

File	Description
__init__.py	Config entries (friendly name, target players, bind IP, HTTP port)
provider.py	DLNAReceiverProvider(PluginProvider) — lifecycle, DIDL parsing, metadata loop, audio proxy
renderer.py	UPnPRenderer — aiohttp server handling SOAP actions (SetAVTransportURI, Play, Pause, Stop, etc.)
ssdp.py	SSDPAdvertiser — multicast SSDP alive/byebye/search responses
eventing.py	GENA event subscription manager (SUBSCRIBE/RENEW/UNSUBSCRIBE/NOTIFY)
constants.py	UPnP URNs, config keys, MIME type mappings
scpd/*.xml	Full service description XMLs for AVTransport, RenderingControl, ConnectionManager
manifest.json	Provider manifest (plugin_provider, domain dlna_receiver)
tests/	37 unit tests covering renderer SOAP handling, SSDP, eventing, provider logic

Notes

• Requires network_mode: host in Docker for SSDP multicast to work
• The existing dlna player provider (MA as DLNA client) is complementary — this adds the server side

Related PRs

• Documentation PR: docs(plugins): add DLNA Receiver plugin page music-assistant.io#626

Source: trudenboy/ma-provider-dlna-receiver · tag v1.0.0

[github-actions]

🔒 Dependency Security Report

✅ No dependency changes detected in this PR.

[OzGav]

Isn’t this the same as #2501 which we just decided not to progress due to security concerns?

[marcelveldt]

Isn’t this the same as #2501 which we just decided not to progress due to security concerns?

I think this one is the other way around. It turns MA into a DLNA target to send audio to (as source)

[OzGav]

Ok then I’m a little confused as to why this is needed as why wouldn’t MA just get the media items directly from where ever the DLNA app is getting them from?

[trudenboy]

Thanks for the question @OzGav - it's a fair one! Let me clarify both the difference from #2501 and the "why" behind this.

How this differs from #2501

	#2501 (DLNA Server)	This PR (DLNA Renderer)
Direction	MA exposes its library outward	MA receives audio from external apps
Security risk	Yes - streaming provider content accessible via unauthenticated DLNA	No - MA never exposes any content; it only accepts incoming streams
Piracy vector	Any LAN client could download tracks	None - the control point already owns/has access to the content
Complexity	Needs full library scanning, stream resolution	Lightweight - just an HTTP/SOAP endpoint that proxies a URL

Why not "just get the media directly in MA"?

This is the key question. There are real scenarios where the audio source cannot or should not be accessed directly by MA:

1. Native streaming apps - Qobuz desktop, Tidal, or other apps handle their own auth/DRM. MA can't always access those streams natively, but these apps can cast to a DLNA renderer.

2. NAS media libraries - users with large FLAC/DSD collections on Synology/QNAP running MinimServer or Asset UPnP. They already have a curated UPnP media server and don't want to re-index everything in MA. With this plugin, BubbleUPnP -> MA -> any player.

3. Phone-as-remote - audiophile apps like BubbleUPnP (Android), mconnect (iOS), HiFi Cast provide superior browsing UIs for some users. They pick music on their phone and push it to a renderer. MA becomes a universal audio sink that routes to its entire player infrastructure (Chromecast, Sonos, ALSA, squeezelite, etc.).

4. Multi-room fan-out - instead of each speaker needing its own DLNA renderer stack, MA acts as a single DLNA endpoint that fans out to grouped players.

5. Third-party apps - audiobook players, podcast apps, DJ software, foobar2000, JRiver - anything that supports UPnP renderer output can now play through MA without any native integration.

In short

The existing dlna player provider makes MA a DLNA controller (MA -> speakers). This plugin makes MA a DLNA target (apps -> MA -> speakers). Together they complete the DLNA story without the security concerns of #2501, since no MA content is ever exposed.

Happy to discuss any architectural or security concerns!

[marcelveldt]

I think it's fine to add it - as long as you take care of maintenance @trudenboy as I am not a fan of DLNA :-)

[Copilot]

Pull request overview

Adds a new dlna_receiver plugin provider that exposes Music Assistant as a UPnP/DLNA MediaRenderer, enabling DLNA control points to discover MA via SSDP and control playback (SOAP/GENA) toward configured MA players.

Changes:

• Introduces a UPnP renderer HTTP server (device description, SCPDs, SOAP actions) plus GENA event subscription/notification handling.
• Implements SSDP multicast advertisement and M-SEARCH responses for discovery on the local network.
• Adds unit tests covering URL helpers, SSDP behavior, renderer SOAP handling, and eventing logic.

Reviewed changes

Copilot reviewed 17 out of 17 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
music_assistant/providers/dlna_receiver/__init__.py	Provider setup + config entries for DLNA receiver.
music_assistant/providers/dlna_receiver/manifest.json	Declares the new plugin provider manifest.
music_assistant/providers/dlna_receiver/constants.py	Centralizes UPnP/SSDP constants and config keys.
music_assistant/providers/dlna_receiver/urls.py	Adds URL validation/redaction helpers (security-related).
music_assistant/providers/dlna_receiver/ssdp.py	Implements SSDP advertise/search response logic.
music_assistant/providers/dlna_receiver/eventing.py	Implements GENA subscriptions + NOTIFY dispatch.
music_assistant/providers/dlna_receiver/renderer.py	Implements aiohttp UPnP renderer (SOAP, SCPD serving, event routes).
music_assistant/providers/dlna_receiver/provider.py	Implements provider lifecycle, multi-renderer management, playback bridging, metadata parsing.
music_assistant/providers/dlna_receiver/scpd/AVTransport.xml	Service description for AVTransport actions/state variables.
music_assistant/providers/dlna_receiver/scpd/RenderingControl.xml	Service description for RenderingControl actions/state variables.
music_assistant/providers/dlna_receiver/scpd/ConnectionManager.xml	Service description for ConnectionManager actions/state variables.
tests/providers/dlna_receiver/__init__.py	Test package marker for the provider’s tests.
tests/providers/dlna_receiver/test_urls.py	Tests for URL validation/redaction helpers.
tests/providers/dlna_receiver/test_ssdp.py	Tests for SSDP advertiser and MX parsing.
tests/providers/dlna_receiver/test_eventing.py	Tests for subscription parsing/timeout/propertyset building.
tests/providers/dlna_receiver/test_renderer.py	Tests for SOAP action handling and SCPD serving.
tests/providers/dlna_receiver/test_provider.py	Tests for deterministic UDN generation and renderer instantiation behavior.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated 5 comments.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated 3 comments.