Windows Media Player cannot access Plex DLNA-Server

[plex2023_1]

Server Version#: 4.116.1
Windows-Media-Player Version#: 12.0.19041.3636

Hi there,

I activated DLNA-Server-Option in my Plex unraid-Server-docker.

In my local network I’m able to playback stored music-files via Yamaha-Amplifier RX-A3020. Playback is also possible via VLC-Player (Windows10pro64bit) or foobar2000 (Android).

But if I try to choose files for playback in my Windows Media Player, I only see plex media server. I can choose Music. But if I choose one of the proposed subfolders (artists, by album, by genre, …, by folder) I only get the error that connection is refused by the remote media library. Contact the manufacturer of the device for further information…?!

Why that?

What is the problem?

Why is WMP not able to playback plex’s DLNA-music-media?

Any idea?

André

[jwillis84]

The current Plex server only implements a [portion] of the Content Directory Service functions that Windows Media Player uses to find content to show in the subfolders in Windows Media Player.

There are two “big” CDS functions; [Browse] and [Search].

Plex currently only supports the [Browse] function, it has a [Search] function stubbed in, but the code is not complete, it returns “null” for now.

Windows Media Player defaults to using the [Search] function to return a folder listing. Right now Plex always returns “null” for everything, so the subfolders appear empty.

Windows Media Player is a convenient and preinstalled DLNA client for most Windows users, you don’t have to go out and download anything and deal with the hassel of installing it.So it is the natural Plex client for most Windows users.

But there are other DLNA clients for Windows you can dowload and install (that don’t look as good or work as well as Windows Media Player) but they default to using the CDS [Browse] function to find content and will show media in the subfolders.

MediaMonkey is the first DLNA server and client I can think of that works and connects to Plex and shows all your content.

MediaMonkey will also serve all your content over DLNA and supports both CDS functions [Browse] and [Search] so Windows Media Player will also show content in subfolders when connecting to a MediaMonkey DLNA server.

But its doesn’t look as good or appear as reliable or native to Windows as Windows Media Player.

I would prefer they just did the extra coding effort and added the CDS [Search] function to the next version of Plex and everything would just work, nice and simple.

There isn’t a way that I know to change the Windows Media Player default behavior from using CDS [Search] to using CDS [Browse]. I rather think its because non-intuitively its a better Browse function than DLNA CDS [Browse] for the things you want to do in Windows Media Player.

CDS [Search] encourages fast and targeted queries, and can be tailored to the purpose. CDS [Browse] strums the entire file system and pulls all that data into a space where you have to trim it down… which is kind of wasteful and hard on the system… its also slow.

But when they were looking at DLNA and thinking about adding it to Plex, they probably were not familiar with it and its history, so they picked the first function that seemed to fit what they were trying to do and now they’ve delivered something that [sort of works] and may have less time to invest in refining their previous choice. So here we are.

They have it stubbed in place… they don’t have to refactor everything… they could just make it sort of a synonym for CDS [Browse] and kind of do the same thing… then Windows Media Player would work… but a true CDS [Search] function could be faster.

Those top level folders Windows Media Player is displaying; in case your wondering… are “media type folders” autogenerated by Windows Media Player to serve as a scaffolding to insert other media and subfolders defined by “type” when they are returned by the CDS [Search] function.

Its not like WMP is going back and forth using [Browse] and then [Search], it always uses CDS [Search].

Until recently, many DLNA clients were coded lazily and defaulted to supporting only one or the other function but not both… now we’re starting to get a few clients like MediaMonkey and DLNA Browser that support both functions.

The reason why was a mystery to me so I went and dug up a 2011 Upnp developers tool kit to Exercise the functions of the Plex server… and that functionary Christmas Tree was kind of bare… compared to the Full Service Windows Media Player.

[jwillis84]

Well… I thought they had it stubbed in… I would have templated it … but … oh well.

We still need the CDS [Search] function to get Windows Media Player working.

Windows Media Player is more than just a DLNA client, its descended from the old Windows Media Connect project which put all three parts into one suite of tools. Media Sharing, Media client and Media remote Controller.

The “Play To” function is a re-branding of DLNA “Remote Control”.

As soon as they recompile Plex with the CDS [Search] function you can also “pitch” a file found in your Plex server to be played on a remote player… like a DLNA TV, or media player… today we would call that “Casting” but you can do it with MediaMonkey… and remotely stop and start it ect… I was curious how “complete” Windows Media Player was… and turns out very.

That’s a 15 year old design… but its pretty robust… even with Win11 and ‘Media Player’ taking the place of Windows Media Player.

UpdateObject is only for changing the file metadata tags.

Remotesharing status is for monitoring a file playing between the Plex server and a Media player after its tosses a coin to that Witcher.

[jwillis84]

There is a way… I vaguely recall… under windows to provide an “Overload” DLL to hook pre-existing functions. Linux (and hence OSX) have something very similar… library overloading.

In this case we just need a CDS [Search] function to provide the ability to Search the Plex server.

It would be trivial for the Plex programmers to write this and recompile their application… but not impossible for someone else to write an Overload DLL that could hook the CDS [Search] call and fix this.

I’m not going to tackle it… but at least if the Plex programmers disappear or don’t implement it… someone could in theory “fix” the problem for not only Windows Media Player, but any other DLNA clients that requires the CDS [Search] function… it might have broad appeal for various DLNA Speakers or TVs that … accidentally require the CDS [Search] function and cannot work with only the CDS [Browse] function.

In this case Windows Media Player merely provides the “incentive” for someone to fill the gap and a way of testing it… then everyone else could benefit from it… think of it as a ‘Bounty’ for a feature.

[jwillis84]

Only thinking out loud.

Microsoft Windows Media Player required/depended on their type of media file to carry attributes in the header or tail of the file for determining media ‘type’ and author, stars, ect…

But Plex uses annotated Library ‘folders’ at the time you create a Library… so a CDS [Search] doesn’t have to check every file to determine its media ‘type’ … it would just test the Library to get all that information for all of the files in that Library… so it could be [obscenely ‘fast’] at returning the results of a CDS [Search] … much faster than anything Microsoft ever produced.

Normally a CDS [Search] could be crafted to “find me all of the video files” - all it would have to do is check all the Libraries for media ‘type’ = video and then construct a list of files from only those Libraries… it would be ridiculously simple to do… the returned query is simple XML or JSON (I’m not sure if its well formed XML) and then the DLNA client… WMP, or anything else, could consume it… we might even have to put in an actual delay to prevent the reply coming back faster than the client could be ready to receive it…

Many of the CDS [Search] options don’t even have to be implemented, since Plex doesn’t police the actual file types put into the Library folders. So things like ‘Author’ or ‘Artist’ could return ‘null’ or ‘blank’ … until such time as that feature was added to the the Plex CDS [Search] function… or it could notice the actual file extension and then decide to dig deeper by accessing those file types with that specific information and populating the return for only those ‘special’ files with that information in the XML/JSON reply stream.