View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0016349||MediaMonkey 5||DLNA/UPnP||public||2020-02-09 22:45||2020-03-05 21:47|
|Target Version||5.0||Fixed in Version||5.0|
|Summary||0016349: Wording changes re media sharing (because of Google Cast support)|
|Description||Currently this dialog: https://www.dropbox.com/s/6f3tun4u7qmx1sf/screenshot%202020-02-09%2023.40.56.png?dl=0 |
includes UPnP/DLNA tab heading which is confusing, because in the list there are also Chromecast devices.
1) I would suggest to rename the "UPnP/DLNA" tab to "Clients" ?
2) '[x] Update play counter for items played over UPnP/DLNA' is also inaccurate when the items are played via Google Cast devices.
Maybe '[x] Update play counter when streaming content' ?
Or maybe '[x] Update play counter when playing remotely' (for consistency with [Auto-conversion] tab wording)?
|Tags||No tags attached.|
|Fixed in build||2229|
Is there any situation in which one would not update the play counter for items played via chromecast output? My understanding of this option is that it should allow users to control whether _remote_clients_ using MM as a _server_ should trigger playcount updates in the library.
It shouldn't allow the user to disable playcounts when they are initiated in MM regardless of whether the output is via:
- DLNA output
- Chromecast output
Which would imply that the wording should remain as is (but the behind the scenes logic for disabling counts based on output choice should be eliminated).
1) You haven't reacted on this item yet, but the rationale is that that if user casts a content to Chromecast and wants to adjust the default auto-covert rules (advanced users more likely) then he needs to go to
Tools > Options > Media Sharing (UPnP/DLNA) > Media Monkey Library (192.168.0.10:53453) > UPnP/DLNA tab > Chromecast Living room > Auto-conversion
Especially the 'UPnP/DLNA' tab name is confusing as the Google Cast clients are also in the list, I would suggest to rename it just to "Clients"
I would also suggest to rename the 'Media Sharing (UPnP/DLNA)' tab in options just to ' Media Sharing' for the same reason.
2) I see what you mean, but in your scenario the MM5 is both server and control point (while Chromecast is renderer), but if MM5 is only the server and the control point is MMA (or Bubble UPnP) then the
'[x] Update play counter for items played over UPnP/DLNA'
is inaccurate, because the protocol used is google cast (and not UPnP/DLNA) !!
Also, why the wording should be inconsistent with the Auto-conversion tab that includes "Convert the following formats when playing remotelly"
So I believe that '[x] Update play counter when playing remotely' is a better wording
Agreed as discussed offline, and added a couple of items:
0) Media Sharing (UPnP/DLNA) --> Media Sharing / Streaming
1) 'UPnP/DLNA' tab --> Clients
2) [x] Update play counter for items played over UPnP/DLNA --> [x] Update play counter when playing remotely
3) In the Global auto-conversion tab append a small item since the global setting is only for UPnP:
Convert the following formats when playing remotely --> Convert the following formats when playing remotely (UPnP/DLNA)
4) Supported formats on UPnP/DLNA clients --> Supported formats on '<XX>' (in this case 'UPnP/DLNA clients' or 'UPnP/DLNA client' or 'Chromecast' [i.e. use a single common string]
5) The only area that I still find a bit confusing is that the list of Client 'devices' mixes output-only 'devices' (Chromecast/DLNA renderers) with DLNA clients (that actually access the library). These two classes of devices are actually very different since:
- Renderers don't require any sort of permission to access the library whereas DLNA clients do (there's no need to 'enable' them, but the UI implies that there is)
- Renderers can be used for _all_ servers (not just the 'MediaMonkey Library' server)
As discussed, a complete fix is unrealistic at this stage for 5.0, but we may want to consider a simple fix that clarifies that renderer-only devices aren't granted access to the library:
i) Change 'Enabled' --> 'Access enabled:'
ii) Force disable renderer-only devices and disable the 'shared content' settings for renderer-only devices
On the other hand i and ii) above can be confusing as well since 'assess enabled' isn't really clear :-( Perhaps we should just add a new column to provide additional context:
iii) Add a new 'Type' column (MMA client/Renderer/etc.)
b) A more complete fix would better differentiate between clients and renderers (per discussion, this is probably too much work to consider for 5.0) i.e.:
Since 'Share automatically with all new devices' is ignored for renderers, rather than add a new column, create separate Tabs for 'Clients' and 'Renderers'. e.g.
[x] Update play counter when playing remotely
[ ] Share automatically with all new devices
Enabled | Mac Address | IP address | Name | Last access
Set custom profiles for output devices
Mac Address | IP address | Name | Profile
0) I would suggest to rename it just to "Media Sharing", as the "Streaming" option is already under Player section (Options > Player > Streaming). Also, see item 5) below at first.
1,2,3,4) added in 2229
5) I don't think that the suggestions above would make the things clearer. Most of users have no idea how casting works so they would hardly search for renderer's auto-convert rules in options.
Also, I guess that most of users won't need to touch the defualt auto-convert rules unless the renderer in quetion is unable to play a media format.
In that case we should rather show a message like:
" RendererX is unable to play C:\file.m4p "
And upon clicking the [Options] the 'Auto-conversion' tab for the particular client would be shown allowing the user to customize and set-up the convert rules?
Another solution could be to show the "gear" icon directly in the cast menu for each renderer (like the Multi-zone has the "gear" icon) and the "gear" icon would link to the auto-covert rules customization. But the "gear" icon should probably be shown only when user is casting a "local" file served via "MM5 server" instance.
0)/5) Without getting into the details of these issues:
Don't you think that a user who wanted to configure chromecast or DLNA output would expect to do so via either:
- Options > Player > Streaming > Play to
- Player|Play to > Options
I think that most users will configure cast/dlna output via the cast icon on the player. But the list of renderers there is the same list as in
- Options > Player > Streaming > Play to
- Player|Play to > Options
i.e. in all these (three) locations the renderers could have the "gear" icon described above. See the attached screengrab to better understand.
Probably the only downside/confusion is that user could have an impression that the auto-conversion is applied also when casting a file from another media server -- which is not true.
cast.png (61,551 bytes)
cast.png (61,551 bytes)
5) Associating the 'gear' with Player outputs sounds good.
a) But would the dialog title be 'Media Sharing' (it's more like 'Media Streaming' or 'Media Output' config)?
b) Would this create config conflicts for chromecast groups vs individual chromecasts?
0) Re. changing the name to 'Media Sharing' that sounds good.
a) Does this mean that Chromecast devices and DLNA output devices would be removed from the list of devices (since they're now accessible as described in 5) and since there's no need to 'enabled' them)?
0) changed name to 'Media Sharing' in 2229
5) re: associating 'gear' with Player otuput. We might want to defer this, because (as I described above) it would give the impression that even playing a file from another media server on the network (e.g. Plex) is re-converted by MM5 (before sending to the remote player). But currently the auto-conversion is really applied only when serving MM5 files (via MM5 server instance) i.e. if we want to go this way then we would need to implement also the auto-conversion from the other servers (which might be tricky/problematic and I doubt that any other app does this).
Therefore I would go the way I previously suggested above (for MM 5.0) based on presumption that most of the users won't need to touch the defualt auto-convert rules unless the renderer in quetion is unable to play a media format. In that case we should show a message like:
"DeviceX is unable to play C:\file.mp4"
=> clicking [Options] brings the [Auto-Conversion] dialog per my screenshot above.
e.g. for Chromecasts we can detect (from the error code) that the media format is not supported, see: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=95807#p465200
Feel free to adjust the wording of the dialog.
5) But wouldn't hiding auto-conversion settings behind a pop-up dialog could cause other issues (e.g. if the user sets a poor rule and then has no way of accessing the dialog)?
Re. the problem that use of a 'gear' next to player outputs "would give the impression that even playing a file from another media server on the network (e.g. Plex) is re-converted by MM5 (before sending to the remote player)", doesn't the UI already make it somewhat clear that these settings apply to the 'MediaMonkey Library' as it appears in the dialog header? Also we could modify the messaging a bit:
Convert the following formats when playing remotely
Convert the following formats when playing '<library name>' content remotely
OK, changing the wording could make it clearer + resolves the issue with accessibility of the dialog.
So let's try to go this way (associating 'gear' with Player otuput) for 5.0
5) Implemented in build 2229 using the 'gear' solution
Tested 2229, and it seems to work well. Just one question:
7) All chromecasts have '[x] Customize for this device' enabled for the auto-conversion rules, but this isn't the case for UPnP devices (i.e. the implication of the current UI is that auto-conversion in enabled for both but only 'Customized' for chromecast devices. Is that accurate? i.e. I would have thought that there's no need for 'Customize for this device' and the UI should just show the line below with a checkbox e.g.:
[x] Convert the following formats when playing 'MedaMonkey Server' content remotely
7) Chromecast profiles _are_ customized (based on https://developers.google.com/cast/docs/media#image-formats ) and differentiates from the default rules for generic client