View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009013 | MMW v4 | Other | public | 2012-01-25 08:26 | 2013-03-01 00:09 |
| Reporter | Ludek | Assigned To | |||
| Priority | immediate | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.1 | Fixed in Version | 4.1 | ||
| Summary | 0009013: Option to use media server as sync server | ||||
| Description | We have added hidden sync server in the course of 0008787 which we use for wifi sync purposes with Android devices. Upon discussion with Jiri over IM, we should also add option '[x] Use as sync server' to media server settings so that: 1. We don't need to run both servers at once 2. User can use advanced server configuration for the sync purposes It should be situated in Options -> Media Sharing -> <Server> -> UPnP/DLNA server tab Note that the option is checked by default and whenever a media server is running (with the option enabled) then the hidden sync server is be stopped. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 1608 | ||||
| related to | 0008787 | closed | Ludek | MMA | Prepare synchronization UPnP server |
| related to | 0008701 | closed | martin | MMA | Select content for synchronization in Android |
| related to | 0008272 | closed | Ludek | MMW v4 | Support DLNA format conversion on a per-client basis (automated?) |
| related to | 0009877 | closed | Ludek | MMW v4 | Initial sync sometimes fails to trigger accept connection dialog on MMW |
| related to | 0009368 | closed | Ludek | MMW v4 | Improved UI for bi-di sync |
| related to | 0008610 | closed | Ludek | MMW v4 | Wireless sync with android devices |
| related to | 0008705 | closed | jiri | MMA | Synchronization UI |
| related to | 0008926 | closed | Ludek | MMW v4 | Ability to pair USB and Wireless key of Android device |
| related to | 0011593 | resolved | peke | MMW v4 | Sync process: Profile Creation, Initial sync can be better automated |
|
|
Note that the '[x] Use as sync server' option could be enabled even for >1 server, which isn't a problem. One thing that was considered was that the 'Content' sheet could define what kind of content is possible to configure remotely by the device. I.e., if [ ] Video is unchecked, it isn't possible to configure it for synchronization by the Android device. That said, this doesn't necessarily be in the first version should there be any problem in the implementation. |
|
|
Fixed in build 1600. |
|
|
Implemented also what Jiri suggested in the note 30051, but there is one problem though. By default no content is checked when a new media server is created. Therefore I changed the defaults to all collections and all playlists. |
|
|
Ok, makes probably more sense anyway. |
|
|
As discussed over IM, this definitely isn't yet as good as we'd like it to have. Needs some more design decisions... |
|
|
There are a few issues that the revised UI should address: - The user should be able to more easily enable/disable Wifi Sync (current location isn't obvious), while retaining the ability to enabled/disable Wifi Sync/UPnP independently of one another. Also, we need to eliminate the redundancy of the two similar 'Allow Wireless Synchronization' and 'Use as sync server' options. - The terminology associated with a sync server shouldn't require the user to understand the concept of a sync server - The user should be able to easily configure the sync profile/auto-conversion settings associated with a wireless device (currently the auto-conversion settings appear to be global per UPnP Server). - The client shouldn't be able to sync/browse if the Server hasn't configured any permissions (e.g. an Android client shouldn't be allowed to access the server unless UPnP security/access permissions have been configured to allow this) The following proposal could deal with all of the above: - A UPnP server would run by default in order to accept remote sync requests. - The UPnP server would be set with the name 'MediaMonkey Server'. It would appear in the list of servers so that the user could terminate the service if desired. Any attempts to disable the last remaining active sync server will yield an error message such as 'Disabling 'MediaMonkey Server' will prevent remote devices from syncing over the network. Do you want to proceed? - This dedicated UPnP Server instance, would have the following non-standard default configuration (see attached): . -Content: all enabled . -UPnP Server Name: MediaMonkey Server . -Mode (this is a new field): UPnP / DLNA and UPnP Sync (other modes are UPnP / DLNA, UPnP Sync) . -Access control: Share automatically....: disabled . -Access control: Notify me....: enabled . -Type (this is a new field): Sync device (others are Player, Controller) As can be seen from above, there are a couple of new functions: 1) Mode selector on the UPnP/DLNA Server config panel that replaces both 'Allow Wireless Synchronization' and 'Use as sync server' options. Other options are UPnP/DLNA, UPnP Sync. The only new string required is UPnP Sync. 2) A Type field on the Access Control panel so that users can easily see sync devices. 3) An options button on the Access Control panel that appears if the user selects a 'Sync Device' (the Device Config Options appear) or 'Player' (a new Auto-conversion dialog appears). Double-clicking a sync device should also have the same effect. Note: - this approach would imply that a client that is a Player and a Sync Device would have 2 separate entries. - unclear what the best approach would be for choosing the default auto-conversion settings for a newly connected device. Perhaps it would be whatever settings are hardcoded? 4) It might be worth changing 'Access control' to 'Remote Devices / Access control' (a new string is needed for 'Remote devices'. See screencaps to see this more clearly... |
|
|
OK, the advantage of the last suggestion is that it accomplish with 0008272. But I see many disadvantages, mainly it wouldn't be intuitive for users. I doubt that anyone would expect that a) Wi-fi sync settings is under Tools->Options->Media Sharing->Media Monkey Server->UPnP/DLNA Server b) Shared media transcoding settings is under Tools->Options->Media Sharing->Media Monkey Server->Remote Devices / Access control->double-click a device c) Tools->Options->Media Sharing->Media Monkey Server->Content defines what kind of content is possible to configure remotely by the android device I think that a, b, c are quite major disadvantages and that much more intuitive would be to leave the separate sync server (that is hidden and is visible only for the Android app), is used exclusivelly for sync purposes and is accessible via Tools->Options->Portable/Audio Devices->[x] Allow wireless synchronization [Configure] and the [Configure] button would brings the server configuration dialog without the 'Auto-conversion' tab, with the 'Remote Devices / Access control' and 'Server' tab, but the 'Content' tab needs to be renamed to clearly indicate its different meaning (defines what kind of content is possible to configure remotely by the android device). Note that on the 'Server' tab the '[x] Enable Play Counter' would be missing for the sync server. |
|
|
With respect to the objections you point out: a) users wouldn't expect that wi-fi sync settings are under the DLNA Server settings: I agree--this can be solved by giving users the option to configure UPnP Sync settings via Device Profile > Options > UPnP Sync. This panel could include the following settings: Allow this device to sync via following UPnP/DLNA Servers: Enabled | Server Name ------------------------ [ ] . . | MediaMonkey Server [Options] b) users wouldn't expect to find media transcoding settings under ->Media Sharing->Media Monkey Server->Remote Devices / Access control->Options: It seems reasonable to me (perhaps we can call this 'Device Settings' instead). c) users wouldn't expect to define shared content via: ->Media Sharing->Media Monkey Server->Content: I agree--but I think that the solution described in a) solves that problem. Summary: I think that this proposal can work, and that if we plan on solving 0008272, it does so within a framework that will resolve all issues. That said, I agree that it might give too much unneeded flexibility. ----------------------------------------------- If we examine the suggested alternative--having a separate sync server that is hidden and visible only to the Android Application as described above: it has it's own set of issues that we'd want to overcome: d) Users never go to the ->Portable/Audio Devices screen anymore. They always go to the <Device> screen, so having '[x] Allow wireless synchronization [Configure]' as a global option there would never be found. As an alternative, on the device summary screen we could have an indicator for the device (e.g. icon or in the profile) indicating: Network Sync: Enabled <Options...> And clicking the <Options...> hyperlink would open the global Network Sync dialog. e) If there's a single dedicated network sync server, then it would presumably be configured along the lines of the defaults described in the previous proposal, BUT it would result in the limitation that all synch sharing settings are limited to a single profile. e.g. if a user wants to share their music with their kids but not their movies, they have no way of doing so. f) If there's a single dedicated network sync server, then in most scenarios, 2 UPnP servers will be running: One for UPnP and one for Sync. I'm not sure of the memory/cpu implications... g) To fix 0008872, we'll have to do so in the manner described in the previous proposal anyhow (i.e. many of the changes required for that issue would apply equally well for this issue, so does taking a different approach for this issue imply wasted effort) |
|
|
I would prefer one single dedicated sync server only for the sync purposes for several real reasons: 1. The purposes and the settings of sync server are way too different from classical UPnP server (at least from user perspective). There is almost no common settings except for IP address that would be same for sync server and classical UPnP/DLNA media sharing server. 2. From the user perspective it will be much clearer. Why should I as a user know something about UPnP if I want just sync wirelessly with my device? I don't care whether it is UPnP or what. As for the objections from the above note: Re d) Whether users go to the Options->Portable/Audio Devices screen or not is dependent on the way how the device is actually connected. If it is connected via USB, he can find the device in the media tree and he doesn't need to go to options. But if the device is connected wirelessly then he needs to go to Options->Portable/Audio Devices screen. I would prefer to have the config there because it would meet the logic that sync server config is not per device, but common for all wi-fi devices. Re: e) I don't understant what you mean, although it is a dedicated server or not then there is the possibility for the server to limit the content that can be configured in the device via Server->Content page (as noted previously). I would rename it to "Allowed content" or something like this. Re: f) I haven't observer any utilization issues running 2 servers at once, have you observed some? Re: g) I don't see any relation between 0008872 and this issue, what is the relation? |
|
|
Re. d) -- Good point, that users _would_ likely go to the Global config screen if no device appears in the tree. BUT if a device appears in the tree, there should be a shortcut to allow the user to configure the wireless options. e) I mean that with the proposed sync configuration there is only a single set of access controls, and that as a consequence there is no way to set up 2 different sets of access controls concurrently. e.g. if I want my device to be able to sync to all movies on the server, but want to limit my kids devices to sync only to specific content, there's no way of configuring this. f) I thought that Jiri had objected to this--I haven't profiled the processes. g) That was a typo--I meant 0008272 Note: I agree that your proposed approach is probably simpler for users. The main remaining issue is e). |
|
|
The finally concluded changes are speeced in this PDF: http://www.mediafire.com/view/?a1dusgg8bea7wut |
|
|
Implemented in build 1601. |
|
|
In order to eliminate the conflict between WiFi Sync and Existing server settings, and prevent unconsented content sharing over DLNA: the following changes in the Media Sharing > Devices panel were discussed (note the changes in default configs): [x ] Share automatically with all new devices [ ] Notify me when a new device attempts to connect ------> Remote Playback (e.g. UPnP/DLNA): [ ] Share automatically with all new devices [x] Notify me when a new device attempts to connect WiFi Sync: [x] Notify me when an unidentified device attempts to sync |
|
|
Re the changed defaults for Remote Playback, I think that the defaults from 4.0 are better, because in most cases WiFi network is just a small local home enviroment where only family members and friends have access, don't you think? |
|
|
Implemented in 1604. |
|
|
As discussed the reasons via email, we are going to simplify the UI to leave just [ ] Share automatically with all new devices that is common for both playback and sync and means: - if disabled (by default): Prompts will be shown for new/unidentified devices - if enabled: No prompts are shown and all conncetions are accepted automatically |
|
|
Implemented in 1604. |
|
|
For testing purposes, here's the full rationale: Currently, we offer the following config options: [ ] Share automatically with all new devices (1) - shares server contents with devices that attempt to connect [ ] Notify me when a new device attempts to connect (2) - notification + option to reject connection a) 1 (enabled), 2 (enabled): Shares, but gives user option to stop sharing b) 1 (enabled), 2 (disabled): Shares automatically, no notification given c) 1 (disabled), 2 (enabled): Doesn't share automatically, but notification appears giving user option to enable sharing d) 1 (disabled), 2 (disabled): Doesn't share, and user isn't prompted to share Jiri suggested that perhaps we should only offer: [ ] Share automatically with all new devices and: - if 'share automatically' is enabled, any device just gets added to the share list (for read-only access to the library), without notifying the user (i.e. get rid of case a)). - if 'share automatically' is disabled [which it is by default], then the user is prompted to: accept the connection, reject the connection, share for all devices (i.e. enable 'Share automatically'), Cancel (in which case the user will be prompted again in the future). If the user wishes to change the config for a device they could just change the config setting that is generated via the prompt, and if they delete the entry, then that prompt would again appear in the future (for that device, provided that 'share automatically' hasn't been enabled). As for Wifi sync, "[x] Notify me when an unidentified device attempts to sync" could be removed and: - if 'Grant remote/sync access rights' is disabled for a particular device, then when that device attempts to connect, MMW user must be prompted with options to: accept the connection (which results in 'Grant remote/sync access rights' to become checked off for that device = adds an entry for the device into the device list), reject the connection, or cancel. - if 'Grant remote/sync access rights' is enabled, then that device should be added to the device list, and when that device attempts to connect, the MMW user wouldn't have to be presented with a dialog (though it could be presented with a dialog if required for other purposes). Note: in the case that the connecting device cannot definitively be matched up to a specific device entry, then MMW should behave as if 'Grant remote/sync access rights' is disabled for that particular device and/or prompt the user to manually connect via USB'. Overall, this seems a lot simpler, BUT it would mean that the DLNA server would have to be run by default in order to accept incoming connections from new WifiSync-enabled devices, giving MMW a larger footprint. Perhaps we can prompt the user about this at installation/first run? Note: on upgrade to MM 4.1, a DLNA Server instance for 'MediaMonkey library' is created, so the absence of that share in 4.0 isn't a problem." |
|
|
Clarification re. wifi sync defaults: Previously there had been agreement that upon creation of a new sync profile over USB, that 'Grant remote access/sync rights' should be enabled automatically. This conflicts with the implicitly assumed behaviour described at http://www.ventismedia.com/mantis/view.php?id=9013#c32838 which states that "if 'Grant remote/sync access rights' is disabled for a particular device, then when that device attempts to connect, MMW user must be prompted with options to: accept the connection (which results in 'Grant remote/sync access rights' to become checked off for that device = adds an entry for the device into the device list), reject the connection, or cancel." since in one case connecting over USB ---> wifi sync rights are granted, but not in the other. Upon further discussion, it was agreed that although it adds an extra level of user interaction, users of MMW would expect that MMW would not share/sync its contents unless they explicitly authorized it. Consequently: In the case of a user creating a new sync profile over USB, 'Grant remote access / sync rights' should be disabled. In other words, wifi sync is never enabled unless: a) the user manually enables it b) the user agrees to enable it when prompted |
|
|
Added to 1604 |
|
|
Tested 1604, and the dialog that appears when a device attempts to connect can be improved so that it's more similar to the identical dialogs that appear on attempts to sync: Current UI: New device has just attempted connection to MediaMonkey Library Do you wish to share data with the device? MAC: xx-xx-xx-xx-xx-xx IP: xxx.yyy.zzz.aaa Client name: bbbbbbbbbbbbb [Yes] [No] 1) Proposed dialog----------> "<SimpleDeviceName> (IP:xxx, MAC: xxx) is attempting to access the MediaMonkey Library. Do you want to allow it to proceed? [Yes] [No] 2) Proposed improvement: The [Yes] [No] options could be expanded to: [Yes] [Yes. Share automatically with all new devices] [No] [No. Disable the UPnP/Sync server.] |
|
|
Re 1) What you mean by <SimpleDeviceName> ? There is no way to find something like this from DLNA client, the only info is included within HTTP header (user-agent) that corresponds to the Client name and is often in non human readable form :-/ Re 2) I don't like the [No. Disable the UPnP/Sync server.] because by disabling the server WiFi sync won't work (this is not clear from user perspective) therefore I wouldn't add the button. I also don't like the [Yes. Share automatically with all new devices] button, because it is too long text, I would rather replace it by simple checkbox, something like this: "bla bla bla. Do you want to allow it to proceed? [ ] Share automatically with all new devices [Yes] [No] ------------------------------------------------- BUT we should also take into account connections from non-private (public) IPs, e.g. user is part of VPN (Virtual Private Network) In that case we should probably rename the [ ] Share automatically with all new devices -> [ ] Share automatically with all new local devices and in case of connection attempt from a new MAC/public IP we would show dialog like this: "bla bla bla. Do you want to allow it to proceed? [ ] Accept external IP addresses [Yes] [No] ----------------------------------------- Note: the current WiFi sync confirmations are tracked here: http://www.ventismedia.com/mantis/view.php?id=8926#c32872 and I like them, I guess we can leave them unchanged, because in case of WiFi sync we always shows confirmations for new connections. |
|
|
1/2) OK, so here's a proposal that deals with the following (which is also mostly consistent with http://www.ventismedia.com/mantis/view.php?id=8926#c32872 ): a) comments above b) Re. private IPs, UPnP and WiFi sync would both work the same wrt external IP addresses (i.e. if the user enables them, it should be enabled for both UPnP and WiFi sync). BUT, I don't think it's a good idea to open MM to external IPs by default because i) it can cause security risks if the user is unaware ii) It would result in stricter settings for UPnP vs Sync, which is kind of strange (e.g. a user could sync to an external IP, but would be unable to play the same tracks). c) Ludek's indication that _only_ MAC address is used to grant permission implies that the dialog's wording should be modified to reflect that access is being granted based on MAC address (current wording implies otherwise): -- Move '[ ] Accept external IP addresses' from the 'UPnP/DLNA Server' to the 'Devices' tab, so that it would show: [ ] Share automatically with new devices (note the change in wording from 'Share automatically with all new devices') [ ] Accept external IP addresses -- Modify the dialog as follows: A device [MAC address: xx-xx-xx-xx-xx-xx] is attempting to access the MediaMonkey Library. Details: IP address: xxx.yyy.zzz.aaa [This is an external IP address!] Client name: bbbbbbbbbbbbb Do you want to grant it access? [Yes] [No] [Options] ([options] would bring the user to the Media Server config dialog) Note the dialog would appear depending on the scenarios described below: [ ] Share automatically with new devices [ ] Accept external IP addresses => acceptance dialog appears [x] Share automatically with new devices [ ] Accept external IP addresses => acceptance dialog appears if the request is from public IP (unless it is a WiFi sync request, in which case it always appears until the particular device has been granted access) [ ] Share automatically with new devices [x] Accept external IP addresses => acceptance dialog appears [x] Share automatically with new devices [x] Accept external IP addresses => acceptance dialog doesn't appear (unless it is a WiFi sync request, in which case it always appears until the particular device has been granted access) -- Lastly, modify the context help for 'Accept external IP addresses' as follows: Permits connections from addresses external to the local network --> Permits connections from addresses external to the local network. Not recommended if Wifi Sync is enabled. and tweak the order of columns in the Status table, to clearly indicate that status is a function of MAC Address. i.e. Date, Status, MAC address, IP address, Client name, Requested file ---> Date, MAC address, Status, IP address, Client name, Requested file |
|
|
Added in 1608. |
|
|
Verified 1626 |
