Add Dlna server Plugin

[OzGav]

My first attempt at a plugin!

This creates a DLNA server which allows playback of local file system files.

In my testing I tried:
Android BubbleUPNP: Worked very well allowing queueing of all artist tracks, or all album tracks or individual tracks
VLC on WIndows: Allowed playback of individual tracks
nPlayer Lite on iOS: Played back individual tracks and albums.

Overall, the plugin seemed to be working and variations in functionality I assess are due to the respective clients. BubbleUPNP for example provides a rich experience with full artwork and full capabilities.

Streaming content is also served

Hopefully satisfies https://github.com/orgs/music-assistant/discussions/388

[MarvinSchenkel]

Just had a little play with this. Nice job!

A few things I noticed:

• Works really well playing local/smb file sources.
• Also works in the dev addon via HA ingress!

Now, it also seems to index media from streaming providers. When opening the 'Artist' folder, it seems to call get_streamdetails() for every track in there, causes a long delay for YTM for example, since resolving streamurls takes 1-2sec per Track. Playing any of the Tracks coming from a streaming provider results in an error.

I think the goal here is to only serve the content from the local/smb file providers? If so, can we configure the plugin to only advertise media items that are provided by local/smb?

[OzGav]

@MarvinSchenkel I think I have to do something. What do you think of only scanning at the track level so you would see the artist then album but inside would be empty if there were no local tracks? Otherwise I think it could be very slow if the provider had to scan every track of an artist just in case one had a local mapping?

[MarvinSchenkel]

@MarvinSchenkel I think I have to do something. What do you think of only scanning at the track level so you would see the artist then album but inside would be empty if there were no local tracks? Otherwise I think it could be very slow if the provider had to scan every track of an artist just in case one had a local mapping?

The library functions should have a provider parameter that allows you to filter on provider. Something like this should work:

Add a constant on the top:
SUPPORTED_PROVIDERS = ("filesystem", "filesystem_smb")

Then inside _get_children(), this should work for artists

artists = []
for provider in SUPPORTED_PROVIDERS:
  artists.extend(await self.mass.music.artists.library_items(
      limit=limit, offset=offset, order_by="sort_name",  provider=provider
  ))
artist_items = [self._create_artist_container(artist) for artist in artists]
total = len(artists)

Of course we will also need this for albums, tracks, album_tracks...

[OzGav]

@MarvinSchenkel Yes I was off on a tangent for a second as I'm doing a million things here. I havent had a chance to test it but I pushed a fix (hopefully!)

[marcelveldt]

This PR has major architectural challenges for which I think we currently do not have the capacity at all. We have about 80 open user issues reports which all have a higher priority than adding this niche feature to our codebase.

Marked as draft and we will revisit this when capacity is in a better place.
For now I think the vibe coding energy can better be spent at solving small user requests and bugfixes.

[github-actions]

🔒 Dependency Security Report

✅ No dependency changes detected in this PR.

[marcelveldt]

should this come from a helper ?

[marcelveldt]

I don't like this because it opens the door for piracy.
we need at least a concept of sessions and attaching these requests to a player(queue) and limit concurrent streams / detect rapid downloads etc.

Also its duplicating logic that we already have in the streams controller.

[marcelveldt]

look what you can unify from the new discovery controller instead of reinventing the wheel

[marcelveldt]

DLNA is an outdated, very insecure protocol. I'm not so sure if we really want to add this support to our codebase.
Do we have some numbers about user demand ?

[OzGav]

I agree with you and the user experience varies considerably by the client software. However, this was actually your feature request 😀 Currently, it is at number 14 of the unimplemented requests with 26 votes https://github.com/orgs/music-assistant/discussions?discussions_q=is%3Aopen+sort%3Atop+-label%3Aimplemented

[marcelveldt]

I agree with you and the user experience varies considerably by the client software. However, this was actually your feature request 😀 Currently, it is at number 14 of the unimplemented requests with 26 votes https://github.com/orgs/music-assistant/discussions?discussions_q=is%3Aopen+sort%3Atop+-label%3Aimplemented

Yeah, I don't think 26 votes satisfies introducing a security risk. Let's focus on high demand requests.
Everything we add also needs maintenance long term.

This PR can be accepted if we find a way to fix the security risks and the open door for piracy - otherwise I'm afraid it has been a waste of your time, sorry!