View Issue Details

IDProjectCategoryView StatusLast Update
0013216MMASynchronizationpublic2019-11-07 10:30
Reporterrusty Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status assignedResolutionnot fixable 
Product Version1.2.0 
Target Version2.1.0 
Summary0013216: Sync to adopted storage fails --> Content migrated to adopted storage fails to play
DescriptionSyncing to an SD card that's encrypted (Marshmallow) fails:

Reported on an S7 at http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=84493

-------------------------------------------------------------

EDIT: This bug is being used to track storage handling issues related to adopted storage. The original problem re. problems with encrypted SD cards is tracked at 0014167 (though it's quite possible that the 2 issues are related).
TagsNo tags attached.
Fixed in build

Relationships

parent of 0014139 resolvedmartin DB Update: Repaired SDCard can get different ID 
related to 0014167 closedmartin On upgrade to 1.3.0 some users cannot play library content (due to encrypted SD card?) 

Activities

marek

2016-05-24 19:47

developer   ~0044736

I asked for log but user didn't answer. I do not have this kind of device.

rusty

2016-05-24 21:09

administrator   ~0044737

Assigned to myself. I'll try to get an s7...

rusty

2017-01-19 18:48

administrator   ~0047016

I tested this on a device with CM13 and was able to replicate the problem. However, I"m not sure if the issue is a MediaMonkey issue since other file explorers couldn't find the music tracks either.

Unless you're able to test/replicate this, I would suggest that we push it beyond 1.3.0, and perhaps even reduce the priority since I'm not sure if this feature is going to remain in its current form or not.

marek

2017-01-19 21:22

developer   ~0047019

Could you please send a log? You have tried the wifi sync? It should use SAF to access files on encrypted SD card. So it uses system API. I am curious about the log....

rusty

2017-01-23 18:59

administrator   ~0047043

Last edited: 2017-01-24 03:00

1 Sync to 'New Downloads' playlist to internal memory and 'test list' to portable sd
--> everything works as expected
--> log TCB8FQTARL

2 Adopt SD card and Migrating internal data to sd
--> all tracks that were synced to internal memory appear in MMA but they're all dead links!
--> log 4BBCUBWRGN
--> However, using an Explorer, shows that the files all appear within as expected within the /Music directory of the adopeted storage.

Note: MMA Options > Library folders shows that the Movies, Music, Video directories on 'Sandisk SD Card' are included in the library. But: 'Primary' (presumably this used to be the reference to internal memory) and '6339-3532' (presumably the reference to the SD card before it was adopted) appear in grey text on this screen.

3 Attempt to configure Wi-Fi sync (KIW-L24 Sandisk SD card -- this is the _only_ available storage location on the device--interesting since it retains the configuration of the 'Internal' storage that had previously been synced. Add 'Test list' to the sync list and sync
--> tracks from both 'New downloads' and 'Test list' sync (even though 'New Downloads' are already on the device).
Sent debug log titled 'bug 13216 @1:30pm, but forgot to note the ID.

4 Attempt to play 'New Downloads' and 'Test tracks'
--> 'New downloads' tracks are still dead links
--> 'Test list' tracks work as expected
Debug log: UPIFLFSJBC

So in summary, it appears that Adopted storage _does_ work for MediaMonkey, however, it only works for tracks that have been synced subsequent to the migration--any tracks synced prior cannot be accessed nor resynced.

5 Migrate data back to internal memory and eject the SD card

6 Run MM and try to access content (tracks or playlists)
--> message 'Connected to computer: Please eject the device in order to access the files!
This error occurs because the SD Card was ejected, but the user didn't 'Forget' the storage device (i.e. the user must first 'migrate data' back to internal memory, then 'eject' the storage device, and then 'forget' it.

It would be useful if a more appropriate error message was shown in this case. e.g. 'The storage location xxx cannot be accessed because it is in use by another process'

7 Forget the device
--> 'New Downloads' Playlist/tracks synced to Internal memory are accessible, but 'Test list' Playlist/tracks that were synced to adopted storage aren't (even though they are visible via an Explorer in internal memory)!
Log: FYHGKKP3A2

EDIT: although 'New downloads' appeared to be accessible and displayed with Ratings and Artwork, after doing a few more sync operations I noticed that the tracks were actually not playable.

marek

2017-03-08 05:41

developer   ~0047431

Well there is quite crazy configuration:

Before adopting:
StorageVolume:
    mStorageId=65537 mPath=/storage/emulated/0 mDescription=Internal storage
    mPrimary=true mRemovable=false mEmulated=true mMtpReserveSpace=500
    mAllowMassStorage=false mMaxFileSize=0 mOwner=UserHandle{0} mUuid=null
    mUserLabel=Internal storage mState=mounted
StorageVolume:
    mStorageId=1679032321 mPath=/storage/6339-3532 mDescription=8
    mPrimary=false mRemovable=true mEmulated=false mMtpReserveSpace=0
    mAllowMassStorage=false mMaxFileSize=4294967295 mOwner=UserHandle{0}
    mUuid=6339-3532 mUserLabel=8 mState=mounted

After adopting:
StorageVolume:
    mStorageId=65537 mPath=/storage/emulated/0 mDescription=SanDisk SD card
    mPrimary=true mRemovable=true mEmulated=true mMtpReserveSpace=500
    mAllowMassStorage=false mMaxFileSize=0 mOwner=UserHandle{0}
    mUuid=ba419257-91fb-444a-b012-d25db983a778 mUserLabel=SanDisk SD card
    mState=mounted

We use mUuid parameter to get UID of storage to build URIs for a file. Usually the UID is null for primary storages (i.e. "primary" UID string is used) and some 9 char string for external storages (6339-3532 in this case). Here the UID is completely different after adopting and I have never seen that and it is probably unusable for building URIs.

The storage is completely different and the media cannot be migrated because it has completely different path, i.e. it behaves like new storage with different data.

But I will try to reproduce it on my phone and find a way how to use such storage.

rusty

2017-03-14 13:56

administrator   ~0047484

Pushed to 1.3.1 (as indicated by Marek, this is mostly fixed in 0013246--MMA just needs to build the URI to access files on adopted storages and sligthly improve USB sync).

For now, the workaround would be to to delete all content from their device (after adopting storage) and then resync--this is what worked for me in testing--Marek to confirm that this should work more generally.

marek

2017-06-20 15:31

developer   ~0048167

I have retested this and it looks like that fixing 0014139 should fix it completely.