View Issue Details

IDProjectCategoryView StatusLast Update
0012967MediaMonkey 4Synchronizationpublic2015-11-24 20:36
Reporterrusty Assigned To 
Status closedResolutionfixed 
Product Version4.1.9 
Target Version4.1.10Fixed in Version4.1.10 
Summary0012967: USB Sync and Wi-Fi sync should copy content to the same location
DescriptionDifferent versions of Android support 3rd party access to SD card directories differently, and different versions of MediaMonkey interact with the different versions of Android in different ways. Moreover, MTP writing to Android devices doesn't have the same restrictions re. what locations on an SD card can be written to. The net effect is that:

1) In the case of Android < 3:
- Wi-Fi Sync sync copies files to the location set in 'Locations'
- USB Sync sync copies files to the location set in 'Locations'
- The 'Enforce sync path...' config works as expected.

2) In the case of KitKat devices:
- WiFi sync copies files based on a combination of an auto-determined root + the configured path from Location settings. The 'Enforce...' config causes files to be moved to the auto-configured location (rather that to the settings that appear on the Locations panel).
- For USB sync, in the past, files were copied according to the Location settings, but _this is a problem_ because it results in different configurations depending on whether or not USB or Wi-Fi sync is used. Based on recent discussions it was felt that they should instead be copied according to the settings of storageinfo.xml (so that Wi-Fi sync and USB sync operations are identical). This would mean that as with Wi-Fi sync, 'Enforce...' would rause files to be moved to the auto-configured location (rather than to the Location specified in the sync settings).

3) In the case of Lollipop + devices:
a) If permissions haven't been granted, then it should work identically to 2)
b) If permissions have been granted, then it works identically to 1)

If we make the change proposed above (to make USB Sync via MTP always follow the 'Location...' settings, then there would be a problem with the config panel that in case 2) and 3a) it's a misleading since the dialog doesn't show the correct location. Perhaps we can change it to:
Sync files to:
Main Directory: _\_____
Music ....
Classical ....

The only objection to having consistent USB/Wi-Fi sync settings is what Ludek had mentioned--that some users may want to sync to \Music with USB even though their device doesn't allow MMA to write to that directory. But I would propose that MMA should not allow such a mode of operation in which via USB and sync via Wi-Fi sync to different locations since it causes other problems (inability to delete files, failed updates/deletions on auto-sync operations, possibility of duplicates re. sync operations?).

Assuming that we go ahead with the above and that MMW will sync over MTP using the same settings from storageinfo.xml, then the 'Enforce...' setting is clear (the UI makes it understood exactly what is being enforced), though there's probably no need to automatically enable it by default. In fact enabling it by default could be a bad idea because:
- MMA can't remove content from the old inaccessible location
- The content may have been stored there in order that other apps have access to it (e.g. movies), and automatically moving it may cause the content to become inaccessible by other apps that the user uses.

Does this make sense? Or is the UI change too risky and/or are there other ways of using the existing UI to ensure that sync paths match for both modes of operation?
TagsNo tags attached.
Fixed in build1768


related to 0012973 resolvedLudek Enforce sync mask causes artwork to be lost in MMA 



2015-11-20 11:09

developer   ~0043345

Last edited: 2015-11-20 11:21

View 6 revisions

Note that it has been already implemented in MMW 4.1.7
i.e. Once MMW finds (from the StorageInfo.xml) that MMA has no write access to the specified locations then it automatically writes it to the MMA's specified location directory.

So this issue is rather about adding an UI for this that would make this clearer for the users and would give users the choice where to sync the content.

Some questions:

a) The first question is how to represent the default root value for the new 'Main directory' config? Should it be just '/' or an empty string?

b) Also looking into localization PO files the 'Main directory' is already localizes/translated which is good. Other localized variants are:
'Destination directory:', 'Directory', 'Directory:', 'Root directory'

Just thinking about the 'Root directory', wouldn't it be better?

c) what should happen when the user updates frmom Kitkat to Lollipop and make the original location writeable for MMA? Should the main directory be automatically changed back to the default root value?
Also I suppose that once the user manually change the default value or the MMA's specified location then it should never be overriden by a permission change, right?


2015-11-20 15:37

administrator   ~0043352

Ahh... Tracks in my environment _were_ syncing to the wrong location, but this was because early MMA 1.1.3 builds probably weren't sharing info from storageinfo.xml correctly (this isn't happening with more recent builds of MMA 1.1.3). In addition, USB sync writing to the wrong location could also have arisen if USB sync occurred prior to installation of MMA on the Android device.

So I suppose the issue is primarily about:
1) how to deal with scenarios where the user finds themselves with some previously synced files in a not-fully-writeable location (SD/Music), but new files being are being synced to an app-specific folder (SD/Android/Data/...) or vice versa. There are 2 cases:
i) An OS/MMA upgrade/MMA installation results in more restrictive wi-fi sync location (SD/Android/Data/...) than previously.
In this case:
-it's to the benefit of all users to automatically sync new files to the app-specific sync location (since wi-fi sync can't otherwise proceed), and perhaps notify the user (as we do today) of the sync restriction.
-it's unclear whether it's beneficial to automatically move existing content to the more restrictive sync location because it would mean that it would no longer be easily shared with other media apps. Consequently, we should notify users of the fact that this can be resolved only via a one-time usb sync, and by setting the 'Enforce...' option.

ii) An OS/MMA upgrade results in less restrictive wi-fi sync locations (SD/Music) than before.
In this case, it's to the benefit of all users to _automatically_ resolve the problem by moving files to the less restrictive sync location (and this can happen via Wi-Fi Sync or USB sync without any user intervention).

2) Modifying config settings that accurately reflect the paths to which new music is being synced (Locations currently show that new music is being synced to SD/Music even when it's actually being synced to (SD/Android/Data/...), without allowing the user to edit the Location to a non-writeable one. This is important both for the user to understand where new files are being synced, but even more so that the 'Enforce...' settings make sense.

To answer your questions:
a) root value should probably be: '/'
b) 'Root directory' seems to be a better choice
c) AFAIK, MMA automatically changes the default storage location according to the heuristics described above at 1) . Perhaps Marek can confirm. I would think that the value of 'Root Directory:' is non-editable by the user and is auto-configured by MMA (all this is doing is displaying to the user what MMW currently implements but hides from the UI).

So to summarize, the proposed changes are:

1) UI
Sync files to:
Root Directory: \ {!} *
Music ....
Classical ....

* root directory is non-editable--the value comes from MMA. It defaults to '\' in the absence of such a value (there's no functional change--MMW just displays what was hidden in the past).

2) Warning indicator
{!} warning indicator / link. The warnings appear for:
- Scenario 1i: "The root sync location has recently changed! Enabled 'Enforce sync mask...' to resync existing content to the new location."

3) If scenario 1ii occurs, automatically enable 'Enforce sync mask...'. Not sure if this is possible??


2015-11-23 13:06

developer   ~0043375

Last edited: 2015-11-23 13:38

View 10 revisions

I am just thinking about the Lollipop devices, currently it can happen that user configure MMA to allow write access to SD/Music, but disallow to write to SD/Video , this results that audio is synced to SD/Music, but video is synced to /Android/Data/...

This would rather imply that we should retain the current UI and probably only add the prefixes directly to the current mask config lines for particular content types?

Sync files to:
Music: [\Music\<Album Artist>\<Album>\<Track#:2> <Artist> - <Title>]
Video: [\Android\Data\...]

the problem is that we cannot make the config non editable, because user couldn't change the mask at all. Maybe just once MMW finds that the path is not writeable by MMA then it auto-adds the \Android\Data\... prefix to the corresponding masks ?

Alertnativelly we could show the non-editable root directory value below the masks and above the [x] Enforce ... options just for the devices with limited access,
i.e. Kitkat devices + Lollipop with a non-default config (at least one location is not writeable) ?
In all the other cases the root directory would be hidden completelly from the UI ?


2015-11-23 13:54

administrator   ~0043377

If the objection raised by Ludek is valid, then the approach that you suggested to 'retain the current UI and just add the prefixes directly t othe current mask' seems to be the most intuitive approach.

Note: perhaps grey out the automatic/non-editable portion of the mask so that users can see that it's not changeable.

Re. the warning indicator described at: 2)scenario 1i, MMW can display the warning next to the 'Enforce sync mask' setting.

Re. 3) scenario 1ii, MMW can still automatically enable 'Enforce sync mask...'


2015-11-23 14:29

developer   ~0043380

Last edited: 2015-11-23 20:29

View 6 revisions

As discussed via IM, the lowest risk and minimal change would be to show the root directory only for the affected write access limited devices as the URL link to a KB article.

Root directory: \Android\Data\... as underscored text (URL to KB article)

Probably placed below masks (to indicate that it doesn't need to be necessary common for all locations) and above the Enforce.. checkbox.
Only the \Android\Data\... should be clickable/underscored to indicate that user can change it (and after the click the user finds how to change it -- thanks to the KB article)


2015-11-23 16:44

developer   ~0043381

Last edited: 2015-11-23 16:45

View 2 revisions

Re scenario 1ii: Marek is saying that whenever MMA gets the write access to the original location then MMA auto-moves the files (it means also for users exclussivelly using the USB sync only)
This sounds to me that in that case we don't need to auto-enable the Enforce option.

The rationale also is that user can make writeable just one folder in MMA and in that case it is unclear whether auto-enabling the Enforce option is a good idea, because it affects also all future sync processes and can result in needless resyncing of many files


2015-11-23 20:13

developer   ~0043382

Last edited: 2015-11-23 21:01

View 7 revisions

Added the Root directory link to KB article in build and

Test notes:
- it is shown only for devices for which at least one mask can produce a read-only path.
- it is shown only when device is connected via USB and MMW can get the necessary info from StorageInfo.xml.

This could be improved in the future once MMA would send the info also via WiFi or the StorageInfo.xml could be cached by MMW, but doesn't seem to be too important at this point.


2015-11-24 20:35

administrator   ~0043394

Testing 1769 and MMA now shows the 'alternative root' for case 1i, along with the help link. It's still kind of complicated, but at least better than before.
Note that if the user syncs via wi-fi, a similar message is provided in the MMA sync UI.

Finally, tested the 'Enforce' functionality via USB sync on a device that had many tracks at /Music even though the OS restricted access to that directory. The functionality worked as expected, however, artwork for all tracks was lost. Workaround was to resync via Wi-Fi. Tracking this issue at 0012973.