View Issue Details

IDProjectCategoryView StatusLast Update
0014480MMASynchronizationpublic2020-03-20 14:14
ReporterLudek Assigned To 
PriorityimmediateSeveritymajorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.3.1 
Target Version1.3.7Fixed in Version1.3.7 
Summary0014480: Android 7's Device Maintenance feature is causing device profile to be duplicated
DescriptionFindings from YLL-339-14661 shown that Android 7's Device Maintenance feature seems to be interfering with MMA's files. Running the feature appears to change the Last Modified date on StorageInfo.xml and delete the other files in MediaMonkey > Files. I believe it even just deleted the MediaMonkey folder wholesale once, which was regenerated upon opening MMA.

Based on the MMW logs the storage guid was really re-generated by MMA (from 9889d636514a523934.0.f83483c6-9313-4d13-99cd-fb260617e5a0 to 9889d636514a523934.0.340ffcdd-da2b-406e-8d84-8ef146913966) by evidence caused by deletion of the files. More details at YLL-339-14661

Based on the findings it seems that MMA should try to backup its storageInfo.xml (or at least the generated storage GUIDs) directly to its private folder to prevent from duplicate profiles creation.
Additional Informationhttps://medium.com/@ssaurel/how-to-retrieve-an-unique-id-to-identify-android-devices-c40080e04fa4 (a bit out of date, but describes high-level considerations)
TagsNo tags attached.
Fixed in build904

Relationships

related to 0013408 closedLudek MMW v4 Device Profiles: Suffix should be added in case profile name already exist 

Activities

Ludek

2017-10-22 16:02

developer   ~0049026

Last edited: 2017-10-23 13:22

Based on the findings it seems that MMA should try to backup its storageInfo.xml (or at least the generated storage GUIDs) directly to its private folder to prevent from duplicate profiles creation.

Nevertheless after uninstalling of MMA there is probably no way how to prevent the maintenance feature to delete the MMA files and thus losing the GUIDs?

So from my point of view the better fix could be to not generate the storageGUID randomly but based on permanent storage properties (serial number or something like that) ? I known that we currently use the device serial number (the first part of the guid , i.e. 9889d636514a523934), but it is common to all storages.

Nevertheless I understand that the permanent storage identifier may not exist, this is also the reason why both MMW and WMP writes its own file with generated key directly to SD card (0012205:0041044)

Ludek

2017-10-23 13:23

developer   ~0049035

BTW currently MMW prefers reading the storageInfo.xml from the private MMA folder and if it doesn't exist there then it is taking the XML from the /MediaMonkey/files/ , so I guess that for now it would be enough for MMA to write the file to _both_ locations.

Ludek

2017-10-26 13:39

developer   ~0049060

Last edited: 2017-10-26 13:46

BTW: just realized that for the permanent storage identifier we could use the storage prefix now? Is this permanent? I mean the values like <prefix>FDAA-0CE7:</prefix> ?

If yes, then we just need to decide whether we will continue to keep SN as the device identifier (that requires permission and isn't available on all devices) or whether we are rather going to use the ANDROID_ID or UUID solution? More about here: https://medium.com/@ssaurel/how-to-retrieve-an-unique-id-to-identify-android-devices-c40080e04fa4

ANDROID_ID solution looks good, but the risk is that user will have two identical devices from the same manufacturer and they would get the same ANDROID_ID :-/ If I undertand the UUID solution would be also suitable, but needed to be used in conjunction with the Android backup feature to persist ater MMA uninstall? Is this feature available on all devices and all Android versions?

Maybe it would make sense to continue using SerialNumber (SN) for devices where the SN is available and doesn't require user permissions and use ANDROID_ID or UUID solution in the other case?

Ludek

2017-10-26 17:06

developer   ~0049063

Last edited: 2017-10-26 18:21

Despite the solution used we might want to re-open 0013408 and instead of adding the suffix we should rather ask user whether any already existing profile is the one (rather than creating duplicate) ?
Currently MMW creates the duplicate profile without asking so users often don't realize that another profile was created and sync settings reset.

i.e. in all the possible approaches there still can be a situation in which we are not sure which profile should be used (e.g. factory reset of the device), in that case we should probably give users the choice.

Ludek

2019-11-11 21:59

developer   ~0055318

I am not sure whether at least 0014480:0049035 was implemented? But according to my tests it wasn't?
i.e. for now it would be enough for MMA to write the file to _both_ locations to resolve this issue.

martin

2020-02-18 01:22

developer   ~0056704

Fixed in build 1.3.7.904

peke

2020-03-04 00:54

developer   ~0057032

Verified 905

Tested, by Manually delete of MediaMonkey Folder, Factory Reset (SDCard was out), Done maintenance.