UPnP 2025 - Continuation of the original UPnP/DLNA plugin

[simbun]

Selecting that preset still seems to force native stream?1

'force native stream' is a global setting and is enabled by default on initial install. I've set it up that way because I expect for 90% of users that will just work without having to do any profile shenanigans.

To offer up another opinion (to be honest I've only skimmed the posts so I have no idea which camp this falls into), I would think the default configuration should aim for bit-perfect playback and compatibility, as such I would expect the profiles to be taken into account - assuming the profiles are configured around the limitations of the devices, not user preference.

As I said I haven't read the posts in detail so I may well have missed the nuance of what @hiccup is asking for, but I can't see a reason why they wouldn't be used.

[BoringName]

To offer up another opinion (to be honest I've only skimmed the posts so I have no idea which camp this falls into), I would think the default configuration should aim for bit-perfect playback and compatibility, as such I would expect the profiles to be taken into account - assuming the profiles are configured around the limitations of the devices, not user preference.

The profiles are taken into account when force native stream is unchecked. 'force native stream' is not a profile specific setting. it's a global setting implemented to allow the plugin to work with minimal user interaction for most users.

There is also a non zero chance the user has a device that doesn't match any of the profiles/presets. In which case 'force native stream' has a much higher chance of working than the generic profile.

This isn't directed at you specifically but It's not something I thought would need defending. For people that don't know what they are doing it has a much higher chance of working, for people that do know what they are doing, uncheck the setting and move on with your life.

And again, not directed at you but as far as I'm concerned, the conversation over 'force native stream' is done.

[simbun]

This isn't directed at you specifically but It's not something I thought would need defending.

Please don't take any of my comments as criticism, I'm sure that everyone on this forum appreciates the work you've done to get it this far already. I don't actually use MusicBee, but I appreciate there's a demand for a Windows desktop UPnP player so I'm just trying to make it the best it can be.

There is also a non zero chance the user has a device that doesn't match any of the profiles/presets. In which case 'force native stream' has a much higher chance of working than the generic profile.

I'd forgot that a Generic Device profile existed. I absolutely agree that the default should be native playback, but when MusicBee knows that native playback isn't going to work (has a matching profile) it seems strange to do it anyway, but that's your call.

I've just downloaded the latest plugin and even with 'force native stream' enabled the maximum picture size (I haven't tested any other profile settings) of the matching profile is honored; should it be?

Given that quite a lot of people will want to disable the global 'force native stream' (I need to for the Sonos (sample rate) and WiiM (picture size) units I've tested) do non-matching renderers still receive the native stream, or will the Generic Device profile apply?

[BoringName]

I'd forgot that a Generic Device profile existed. I absolutely agree that the default should be native playback, but when MusicBee knows that native playback isn't going to work (has a matching profile) it seems strange to do it anyway, but that's your call.

You're probably pushing the criticism line there.... In any case, could I work out if devices can natively play back a certain format ahead of time? Maybe.... but when they use the same useragent for multiple models which have different capabilities and don't always follow the UPnP standard, I'm not prepared to play the trial and error game.

I've just downloaded the latest plugin and even with 'force native stream' enabled the maximum picture size (I haven't tested any other profile settings) of the matching profile is honored; should it be?

Image size is profile specific and separate from the stream format. The other Voldemort setting you mentioned is not profile specific. If the device useragent doesn't match an existing profile it will use the image size for the generic profile. 160px is the default for the UPnP standard, any device claiming to support the standard should accept that resolution.

Given that quite a lot of people will want to disable the global 'force native stream'

Careful now, someone might make you defend your assumptions.

If you untick that will shall not be named, the plugin will use whatever profile settings match the device useragent, if there is no match it will use the generic profile settings which has a decent chance of not working, hence the last 2 pages of discussion.

[simbun]

If you untick that will shall not be named, the plugin will use whatever profile settings match the device useragent, if there is no match it will use the generic profile settings which has a decent chance of not working, hence the last 2 pages of discussion.

I've read the last few pages and this just doesn't make sense to me, so I must be missing something.

My current understanding is

With 'force native stream'
- the source file is sent to the renderer without any checks at all.

Without 'force native stream'
- check to see if the renderer supports the source format (using the list of mime types provided by the renderer)
- check if source resolution, bit depth and channel count  is supported (against the Generic Device profile if a matching profile doesn't exist)

If any of those checks fail the source is transcoded to PCM, which I believe is supported by all renderers - although I've been unable to confirm that as I can't find the DLNA specification.


Assuming that everything else remains the same (UPnP communication wise) why would a 44.1 kHz PCM file be more likely to fail than a 48kHz Opus/192 kHz FLAC?

[hiccup]

I've read the last few pages and this just doesn't make sense to me, so I must be missing something.

I think you have a pretty good idea.
I still don't understand it either.

Note that I am all for:
1.  making things as easy as possible for less-savvy users ('it just works' is what elevates MB over other players and their plugins such as fb2k)
   (damn, how I love BoringName's VUmeter plugin more every time I see how they are struggling and complicating it over there at fb2k)
2.  allowing more-savvy users to achieve what they are aiming to do

The way 'force native stream' is currently implemented doesn't serve either in my opinion.
-  for less-savvy users, I don't see how it would work better than having some 'default' setting that simply transports/encodes everything adhering to the most basic and minimal UPnP/DLNA standards. (the last described DLNA standard dates back to 2016, so all get aboard the yellow time machine)
-  for more-savvy users I understand why when they e.g. select a preset, they are confused why it won't work, maybe later finding out that it's because there is some sticky checkbox with a 'global' label that trumps and defeats what the preset they have intentionally selected was designed for and is supposed to do.

So neither the less-savvy nor the more-savvy users will probably understand what is going on or how things work exactly.

The logic behind the current implementation just seems flawed to me, and I think this discussion is proof enough that this deserves a fresh look and some serious rethinking.
(a porch, a dog, a cigar, a sunset)

[jean.valjean]

Hello,

Version 1.9.3 and 2.0.2

For Marantz users, do not update your devices. The new firmware prevents the plug'in from working properly.

Radios no longer work in continuous streaming. The device goes into standby mode after a certain time, even if a playlist is running. Device no longer displays format and time remaining. The last song in the playlist starts, then the playlist stops.

It's the same with the jellyfin media player and its dlna plug'in.

Translated with DeepL.com (free version)

[BoringName]

With 'force native stream'
- the source file is sent to the renderer without any checks at all.

Correct.

Without 'force native stream'
- check to see if the renderer supports the source format (using the list of mime types provided by the renderer)
- check if source resolution, bit depth and channel count  is supported (against the Generic Device profile if a matching profile doesn't exist)

It checks if the mimetype is supported.
It only checks resolution and bit depth for L16/L24/Wav mimetypes. it doesn't check channel count.

If any of those checks fail the source is transcoded to PCM, which I believe is supported by all renderers - although I've been unable to confirm that as I can't find the DLNA specification.

It's transcoded to whatever is set for that profile and your assumption that all renderers support PCM is incorrect.

Assuming that everything else remains the same (UPnP communication wise) why would a 44.1 kHz PCM file be more likely to fail than a 48kHz Opus/192 kHz FLAC?

I don't really know why you are making that comparison. It's got nothing to do with PCM vs whatever or what formats are compatible with what devices. It's got to do with settings that will work for the most users out of the box.

My argument is for 'most' users, 'force native stream' will work out of the box with the plugin. They can just install the plugin, set their device as the output and it will work. That means they won't have to open the plugin settings at all and less people needing support. It's a no brainer as far as I'm concerned.

If you can prove my argument wrong. I'll consider changing it.

Pointing to a specific format/device combo does not prove that argument wrong.

[BoringName]

Radios no longer work in continuous streaming.

Radio streams are partially supported now when continuous stream is unchecked. The streams cannot be encoded by the plugin so it all comes down to whether the device supports the stream format.

[BoringName]

-  for less-savvy users, I don't see how it would work better than having some 'default' setting that simply transports/encodes everything adhering to the most basic and minimal UPnP/DLNA standards.
(the last described DLNA standard dates back to 2016, so all get aboard the yellow time machine)

In a perfect world where all devices supported the standard correctly that might almost work.

-  for more-savvy users I understand why when they e.g. select a preset, they are confused why it won't work, maybe later finding out that it's because there is some sticky checkbox with a 'global' label that trumps and defeats what the preset they have intentionally selected was designed for and is supposed to do.

So if you had a choice, would you make it harder for less savvy people or make it harder for more savvy people? Keep in mind the more savvy people will also have a higher chance of it working out of the box and would also be more capable of figuring out why it doesn't.

[hiccup]

So if you had a choice, would you make it harder for less savvy people or make it harder for more savvy people?

My aim is, and always has been to make things as easy and logical as possible for less-savvy users.
Which is why I have a gripe with how 'force native stream' is currently implemented.

A scenario:

A MusicBee user has Squeezebox devices, and learns that there is a plugin that allows him to use MusicBee to play his music on them.
Great!

So he installs UPnP2025, and sees that there is even a preset for LMS (his Squeezeoxes) available.
Great again!
So he selects that preset, and starts playing his music.

Finding out that not all of his music will play.
Not having any clue whatsoever why that is.
Not so great.

This could be easily avoided if the 'force native stream' entry would follow the value that a preset has for it.

---

About having 'force native stream' the default because it is likely to work best for the majority of users/devices: I just doubt that, but if you are convinced that it is, no problem, I can obviously respect that.

But it shouldn't break the functioning of carefully created and tested presets without any clue or visual indication to the user.

---

edit
Perhaps another approach could be to have two generic presets at the top.
Something like:

-  Generic (basic UPnP/DLNA)
-  Generic (force native stream)

Then a newbie who is not interested in diving into the technicalities could simply try which of these two works best for him.
 

[BoringName]

So he installs UPnP2025, and sees that there is even a preset for LMS (his Squeezeoxes) available.

Your forgetting a majority of people wouldn't even need to open the settings with fns ticked. And squeezeboxes are not a great example because LMS does it's own conversion for unsupported formats which is even more reason for the plugin to just use native streams. In any case, it's really only an issue if the device does not support whatever format the user has their library in. I could be wrong but I would think a large majority would be using mp3/AAC/Flac which would be supported natively by most modern devices.

This could be easily avoided if the 'force native stream' entry would follow the value that a preset has for it.

The whole purpose of fns is to ignore presets.

About having 'force native stream' the default because it is likely to work best for the majority of users/devices: I just doubt that, but if you are convinced that it is, no problem, I can obviously respect that.

Based on all the testing I've done with multiple renderers, Native stream not only has a higher chance of playing across multiple formats but also has a higher chance of the device displaying the correct progress and seeking working successfully. The way musicbee and the plugin interact with encoded streams limits what metadata can be pre-calculated and sent to the device. This effects seeking functionality and whether the device will display the correct progress values. ie) it's always best to use a native stream if possible.

But it shouldn't break the functioning of carefully created and tested presets without any clue or visual indication to the user.

It doesn't break anything. Force Native Stream is about as clear as it can be on what it means, it also has a tooltip for further clarification. I expect the only time users will even have an issue is when they try and play a less popular codec and it doesn't work. Then they have to do a little research to figure it out, I'll take that over making everyone look over the settings unnecessarily.

edit
Perhaps another approach could be to have two generic presets at the top.
Something like:

-  Generic (basic UPnP/DLNA)
-  Generic (force native stream)

Then a newbie who is not interested in diving into the technicalities could simply try which of these two works best for him.
 

I'm not doing that. Again, most of them wont even need to look at the settings page with fns ticked by default.

[hiccup]

Your forgetting a majority of people wouldn't even need to open the settings with fns ticked.

I don't think I 'forgot', and it's perfectly fine and understandable that you are trying to make the plugin work as good as possible out-of-the-box without any further user action.

I'm not doing that. Again, most of them wont even need to look at the settings page with fns ticked by default.

So that means that in your opinion, any user that does open the settings panel and selects a preset should have a good understanding of both what FNS does, and how the interface does not reflect if a preset is even respected.

I keep disagreeing on that and believe it is a fundamental flaw.
Both in logic and in UI.
But discussing it further doesn't seem to bring us any closer at all, so it's probably best to leave it at this.

edited for typos and making my standpoint a bit clearer.

[simbun]

Based on all the testing I've done with multiple renderers, Native stream not only has a higher chance of playing across multiple formats but also has a higher chance of the device displaying the correct progress and seeking working successfully. The way musicbee and the plugin interact with encoded streams limits what metadata can be pre-calculated and sent to the device. This effects seeking functionality and whether the device will display the correct progress values. ie) it's always best to use a native stream if possible.

There are some very good reasons there.

How about we remove the 'force native stream' option (it's still the default behaviour) and instead of enabling/disabling fns globally to use profiles, we activate each one individually? So an LMS user would just enable/activate the LMS profile and all their other non-LMS renderers would still be sent the native stream.

[BoringName]

So that means that it in your opinion, any user that does open the settings panel and selects a preset should have a thorough understanding of both what FNS does, and how the interface does not reflect if a preset is even respected.

I think you have misunderstood how profiles work. They don't need to be selected. Any device whose useragent matches a profile will use those settings (if fns is unchecked). Selecting a profile on the settings page just allows you to change settings for that profile, it doesn't make it the default profile for all devices.

In any case, yes, if someone opens the settings page I expect them to read the tooltips. fns is listed as a global setting. I don't think I need to dumb it down further.

Having a profile isn't a magic bullet, useragents can be shared amongst devices, there is no guarantee they will work.