View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0013246 | MMA | DB | public | 2016-04-25 21:51 | 2017-04-26 01:20 |
Reporter | marek | Assigned To | |||
Priority | urgent | Severity | feature | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.2.0 | ||||
Target Version | 1.3.0 | Fixed in Version | 1.3.0 | ||
Summary | 0013246: Rework the way how the path to file is stored to DB and preferences | ||||
Description | We currently use the standard path like: /mnt/sdcard/Music or /storage/sdcard/Music But this form of path to file has some shortcomings: 1. It cannot be used for USB mounted drives that doesn't have any mount point 2. The path can change once the Android is upgraded and it is quite hard to detect it and update DB correctly 3. Multiple storages can be mounted to same mountpoint Since Android 5.0, google started to use Document ID, which is specific form of path: 12AB-CD34:Music/Some artist/, where 12AB-CD34 is UID of storage and it is unique for each storage (even different SD cards and USB flashdisks). The rest of Document ID ('Music/Some artist/') is relative path on storage. So it is much more universal and it solves all three shortcomings of standard path. We are already using it everywhere (in 1.2.0). It is only not used in our DB and preferences. The only shortcoming of Document ID is that the storage UID is not available on pre-Lollipop devices. But this can be workarounded by simple replacement of UID with specific form of storage root path that will look like UID (already implemented in 1.2.0): /storage/sdcard/Music/Artist -> storage-sdcard:Music/Artist | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
Fixed in build | 676 | ||||
related to | 0013244 | closed | marek | MMA | File browser use deprecated java.io.File interface |
related to | 0013122 | closed | marek | MMA | Size of artworks and tracks differs on some devices with Marshmallow |
related to | 0013387 | resolved | marek | MMA | Wifi Sync: delete performance is slow in 1.2.0 |
related to | 0013247 | resolved | Ludek | MMW v4 | Change the way how MMW process path in MMA DB |
related to | 0013481 | closed | marek | MMA | Scanned folders might be lost |
related to | 0013525 | closed | marek | MMA | All data lost upon running MMA Beta |
|
Other needed changes: a) DeviceConfigProvider should accept UID instead of root path b) rework storageInfo.xml as described in 0013247 |
|
Fixed in build 1.2.1.650 |
|
There were still issues with processing path in build 653 - processing of artworks - deletion of media files Fixed in build 654 |
|
reopen After clean install of MMA 654 and restart LG verizon do not see SDCard where reinstalling 653 sdcard is back on list 653 log: 7UXHAL1Z73 desc: sdcard653 654 log: ZNY58SJPFZ desc: sdcard654 |
|
I have fixed one issue in storage processing in build 655 But there is still some suspicious behaviour (even in 653). The storage is sometimes recognised as SAF storage in Android 4.4. That is not possible. SAF is supported since 5.0. I have added some logs. So please test it and send logs (from this LG device) even if it looks like working. |
|
Even I'm now capable to browse and add folders to Library after sync tracks are not available and ther was loading screens not stopping till I exit the folder on SD card. Logs are sent along with ids to IM. |
|
Peke indicated that it is fixed. It was probably caused by some old data from previous build. We should not use builds 650 - 654. It can corrupt the settings. Upgrade from 1.2.0 should be tested instead. |
|
Verified 656 Confirming Upgrading from 1.2.0 to 650-654 and then to 656 always corrupt settings. Problem is raised as on some devices like LG Verzion on android 4.4.2 SDcard/MediaMonkey/MediaInfo.xml got corrupted and could not be refreshed/cleaned due LG customization to override SDCard permission limitations in 4.4.x systems. |
|
In build 665, there are following issues: 1. When tracks with failed artworks are deleted, app crashes on next start 2. Upload of tracks during wifi sync can fail - when using SAF api 3. M3U files are stored incorrectly - paths has to be converted from document ID to absolute path 4. Tracks that are on unmounted storages cannot be deleted |
|
Fixed in build 666 |
|
Verified 667 Tested with clean 1.3.0.667 and upgrade from 1.2.0 -> 1.3.0.667 to see if Both Internal and SDcards (where available) sync work and that all tracks are scanned no matter if they are existing or synced. Test cases: LG Verizon 4.4.4 = passed Done three tests and in the past due the hybrid approach SDCard tracks were not in library on scan Asus MemoPad 7 HD 4.1.2 = Passed ZTE Blade Q 4.2.2 = Passed Nexus 7 2012 CM13 = Passed (Internal only and browsing USB) Nexus 7 2013 6.0.1 = Passed (Internal only) Moto G LTE 5.1 HTC Desire 820 6.0.1 |
|
Re verified 671 |
|
Tested 671 with Nexus 5x: 1. Track deletion - OK 2. Upload of track from MMA to MMW fails! 1 Copied Ed Sheeran - Shape of You to device (/Download/Music) 2 Added /Download/Music to the MMA library 3 Verified that the file appeared and plays in MMA 4 Updated the sync profile to sync bi-directionally to /Users/Russell/Downloads (and included the /Download/Music directory from the device) 5 Initiated wi-fi sync --> track fails to copy! Debug log: QSLFFQSCRG 3. OK |
|
Fixed in build 672 There was deprecated SQL query generator that didn't work with document ids. Fixed and added tests for this generator. |
|
Verified 672. |
|
Media from remote paths(Wifi sync) are deleted on update do documentId path format when storage is not available. Request to keep these media in database. Show paths of such media in Options/Choose library folders. |
|
Fixed in build 1.3.0.674 |
|
Fixed SQLiteException in special case in build 1.3.0.676 |
|
Verified 679 |
|
Fixed in build 695 List of all folders (including old folders) was obtained incorrectly. Tests were updated to work with current implementation. |
|
Verified 695 |