|
|
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: - MM - 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. Clients [x] Update play counter when playing remotely [ ] Share automatically with all new devices Devices: Enabled | Mac Address | IP address | Name | Last access -------------- Renderers 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 " [Options] [Cancel] 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) |
|
|
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" [Options] [Cancel] => 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 |
|
|
7) But don't all chromecast devices use a common / predefined media profile (i.e. 'Customized for this device' implies that the user has set some custom settings that override the default settings for chromecasts)? Not a big deal, I just don't understand why this is any more 'customized' from the default auto-coversion settings than the UPnP profiles. 8) I noticed that chromecast audio devices are configured with supported video: m4v, MP4, WEBM, but afaik, no video should be sent to a chromecast audio. Also I guess that the auto-conversion rule for video should be disabled. But can MM even detect that a device is a chromecast Audio (w/o video support)? 9) I haven't tested video playback to a chromecast for unsupported video formats. Is MM supposed to stream all such content? Or does it convert the entire file and then stream it? |
|
|
7) There is the default auto-convert profile per server (Options > Media Sharing > [[server]] > Auto-conversion ) , but because Google Cast devices are specific (and we know the supported formats) then they get the _customized_ profile by default. 'Customize for this device' means that the default server settings is overriden by settings for this particular client. So maybe just the wording is unclear and should be rather "Customize for <<client name>>" On the other hand I believe that the checkbox should be completelly hidden when the configuration is accessed via the 'gear' icon associated with player output. Because in this case it is self evident that the rules are configured just for this particular device/client and not globally. 8) Just tested playing unsupported video (*.AVI) to Chromecast Audio, it was converted to WebM and played on the 'Chromecast Audio' as audio successfuly (i.e. user can listen to his TV series this way). So I guess that it works as expected and no change is required. 9) It converts to WebM on-the-fly (originally implemented as 0014530) |
|
|
7) OK, thanks--I think I understand better. Are you saying that for the user to play to a Chromecast device, s/he must enable Media Sharing? I'd thought that the '[x] MediaMonkey Library' only needed to be enabled if the user wanted to share the library or give access to a UPnP controller. But iiuc you're saying that the 'MediaMonkey Library' server and it's settings also apply to MM-->CC playback and must therefore be enabled to play to a CC device. Is that right? 8/9) OK. Thanks. |
|
|
7) By default the 'MediaMonkey Library' default server is used, but if the media sharing is not enabled and no server is running then a temporal "invisible" media server is run just for the casting purposes. But (as I said) the Google Cast devices has the rules customized per client/device (despite the server used) so there isn't a difference. |
|
|
7) I don't think that changes in wording would make much of an improvement. The confusion stems from the fact that unclear (for Podcasts and UPnP) what exactly is being customized. The simplest solution might be to have a button on the lower left for [Default Auto-Conversion rules...] that links to the default rules so that the user can understand: - whether customized rules are, in fact, necessary - what exactly is being customized in comparison to the default rules |
|
|
7) I believe that the only confusion is that the ' [x] Customize for this device' checkbox is even present when the auto-convert config is accessed via the 'gear' icon associated with the player output. In such a case it does not make sense to show this checkbox as the configuration needs to be always per-client (despite the server used). So I removed the checkbox in 2251 |
|
|
Verified UI in 2251. |
- Anonymous
