View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013216 | MMA | Synchronization | public | 2016-04-08 16:37 | 2019-11-07 10:30 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | assigned | Resolution | not fixable | ||
| Product Version | 1.2.0 | ||||
| Target Version | 2.1.0 | ||||
| Summary | 0013216: Sync to adopted storage fails --> Content migrated to adopted storage fails to play | ||||
| Description | Syncing 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). | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
I asked for log but user didn't answer. I do not have this kind of device. |
|
|
Assigned to myself. I'll try to get an s7... |
|
|
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. |
|
|
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.... |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
I have retested this and it looks like that fixing 0014139 should fix it completely. |
